Using bintime() in acpi_cpu_idle()?

[Alexander Motin]

On 30.07.2012 09:25, Alexander Motin wrote:
> On 30.07.2012 07:33, Bruce Evans wrote:
>> On Sun, 29 Jul 2012, Alexander Motin wrote:
>>
>>> On 29.07.2012 15:26, Bruce Evans wrote:
>>>> On Sun, 29 Jul 2012, Alexander Motin wrote:
>>>>
>>>>> On 29.07.2012 11:37, Bruce Evans wrote:
>>>>> ...
>>>>>> binuptime() is more accurate than uncalibrated scaling.  Is accuracy
>>>>>> required?
>>>>>
>>>>> Accuracy is not required at all. +-20% is not a problem.
>>>>>
>>>>>> If not, the CPU ticker might work, and is faster than HPET,
>>>>>> and and is not under user control for perverse settings.  It normally
>>>>>> reduces to readtsc() with no serializing instruction even in proposed
>>>>>> changes.  This is good enough for process times (not very good) and
>>>>>> depends on the CPU not changing.  Its calibration is very accurate
>>>>>> (similar to timecounters) modulo bugs, but not always up to date.
>>>>>
>>>>> Problem with ticker that it may stop during idle periods, and idle is
>>>>> exactly what happens here. Unlike timecounter usage here we don't need
>>>>> CPU synchronicity, but we need it working during deep sleeps.
>>>>
>>>> The ticker is the same as the timecounter in many cases of
>>>> interest.  If
>>>> the TSC stops then it cannot be used for timecounting unless
>>>> timecounting
>>>> is reinitialized.  Timecounting should be reinitialized after deep
>>>> sleeps,
>>>> but you say you need it to work during deep sleeps.
>>>
>>> Timecounter already has detection logic to disable TSC in cases where
>>> it is unreliable. I don't want to replicate it here. I need not
>>> precise and not synchronized by reliable and fast time source.
>>
>> Yes, this logic gives exactly what you don't want (an inefficient
>> timecounter), by preventing use of the TSC for the timecounter, although
>> the TSC is perfectly usable for the ticker and here.
>
> Can you teach me how to use ticker that is not ticking? If TSC was
> considered unusable for timecounter for reasons unrelated to SMP, how
> can I use it as ticker.
>
>>>> I wouldn't trust timecounters for some time after waking up after a
>>>> deep sleep.  If their clock stopped then the times read might only be
>>>> very out of date.  If their clock didn't stop, then they might have
>>>> wrapped or otherwise overflowed and the times read would be garbage.
>>>> Is there any locking or ordering to prevent them being used before they
>>>> are reinitialized?
>>>
>>> I am not sure what reinitialization are you talking about. IIRC, there
>>> is no any waking up code for TSC. None other time counters have
>>> problems with C-states.
>>
>> It is the timecounter code that needs reinitializing.  If the TSC stops,
>> or wraps mod 2**32, then its counts become garbage for the purpose of
>> timecounting.  Maybe it is not used for timecounting in either of these
>> cases.  But these cases shouldn't prevent its use for timecounting.
>>
>> The 2**32 number is because timecounters only use 32 bits of hardware
>> counters (for efficiency).  So even if the hardware has some magic to
>> not stop the TSC while sleeping (maybe it fakes not stopping it be
>> reloading on wakeup), it is still unusable by timecounters after sleeping
>> for a second or 2 so that it wraps.  The software needs similar faking
>> to reload the timecounter on wakeup.  This makes use of timecounters in
>> sleep/wakeup code fragile.
>
> At this moment I am not talking about S-states sleeping for hours. I am
> talking about C-states for milliseconds. It means that TSC may stop and
> start 10K times each second or even more. Attempt to save and restore
> its state will consume so much resources, that probably make it useless.
>
> What's about wrap after 2 seconds, I would be happy to make CPU sleep
> for so long, but now 100ms is all I can hope even on idle system.
>
>> At boot time there is a dummy timecounter that returns bogo-times.
>> Apparently sleeping doesn't occur before the timecounter is switched to
>> a real one.  The dummy timecounter isn't switched back to after boot
>> time.  But it probably should be, since the hardware timecounter may
>> have stopped or wrapped.  Sleeping could just set a flag to indicate
>> this state, but then you would have to provide a fake time anyway on
>> finding the flag set.  Boot time just points to the dummy timecounter
>> so as not to check this flag in all early timecounter "hardware" calls.
>
> And how dummy timecounter that counts something, but not time, can help
> me to measure sleep time?

Nevermind, let it be compromise solution -- ticker for C1 state where 
performance is the most important and where TSC works and ACPI timer for 
others.

-- 
Alexander Motin