Re: [2.6.0-mm2] PM timer still has problems

[john stultz <johnstul@us.ibm.com>]

On Tue, 2004-01-06 at 22:30, Dmitry Torokhov wrote:
> On Tuesday 06 January 2004 03:31 am, john stultz wrote:
> > On Sun, 2004-01-04 at 22:17, Dmitry Torokhov wrote:
> > > I decided to go hpet way and use tsc in ACPI PM timer to do delay
> > > stuff and monotonic clock.
> >
> > I think you have a valid point that as loops_per_jiffy isn't updated,
> > delay_pmtmr() and delay_pit() are broken w/ CPUFREQ.
> >
> > However I don't understand using the TSC for montonic_clock. I have no
> > clue why the HPET folks implemented it that way (likely my fault for
> > not enough documentaiton), but I haven't had the time to try to clean
> > up that code. And really, if your TSC is reliable enough for
> > monotonic_clock, why are you using the pmtmr? :) Unless it specifically
> > is resolving an issue, I'd drop that change.
> 
> I thought (it seems that I was mistaken) that the goal of monotonic_clock
> is to privide high-resolution cheap timestamps that are guaranteed never
> go back as there is no adjustments to the time. The normal clock it supposed
> to be stable and accurate but probably give lower resolution. In case of
> pmtmr vs. TSC seems to have higher resolution and is cheap so it was used.

Indeed never going back in time was an important part of the goal, but
it also is supposed to give the number of nanoseconds that have past
since boot. If the TSC is unsynched or changes frequency then we cannot
provide that. Additionally if the TSC is unsynched, monotonic_clock can
go backwards when using the TSC. 

If someone wants a highres and possibly inconsistent timestamp (somewhat
like sched_clock uses), get_cycles() provides that interface. 

thanks
-john