Re: CONFIG_X86_PM_TIMER is slow

[Willy Tarreau <willy@w.ods.org>]

On Thu, Nov 11, 2004 at 11:43:14PM -0800, dean gaudet wrote:
 > >         do {
> > >                 v1 = inl(pmtmr_ioport);
> > >                 v2 = inl(pmtmr_ioport);
> > >                 v3 = inl(pmtmr_ioport);
> > >         } while ((v1 > v2 && v1 < v3) || (v2 > v3 && v2 < v1)
> > >                         || (v3 > v1 && v3 < v2));
> > 
> > Just a thought : have you tried to check whether it's the recovery time
> > after a read or read itself which takes time ?
> 
> each read is ~0.8us ... the loop only runs once.

OK, but here, 2 of these 3 reads are done after another one.
For example, does it change anything to add something like this :

do {
   volatile int slow;
   v1 = inl(pmtr_ioport);
   for (slow = 500; slow--;);
   v2 = inl(pmtr_ioport);
   for (slow = 500; slow--;);
   v3 = inl(pmtr_ioport);
} while ...

If it does not change anything, then it means that there is a recovery
time after a read, which would imply that the 3 back-to-back reads are
more harmful than it seems.

> > Other thought : is it possible to memory-map this timer to avoid the slow
> > inl() on x86 ?
> 
> that's how the even newer HPET works ... but not all systems have HPET.

OK, thanks for the info, I didn't know about that.

Regards,
Willy