Using bintime() in acpi_cpu_idle()?

[Alexander Motin]

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.

> 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.

-- 
Alexander Motin