Re: CONFIG_X86_PM_TIMER is slow

[dean gaudet]

On Fri, 12 Nov 2004, Willy Tarreau wrote:

> >         /* It has been reported that because of various broken
> >          * chipsets (ICH4, PIIX4 and PIIX4E) where the ACPI PM time
> >          * source is not latched, so you must read it multiple
> >          * times to insure a safe value is read.
> >          */
> >         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.

> I mean, perhaps one read
> would take, say 50 ns, but two back-to-back reads will take 2 us. If
> this is the case, having a separate function with only one read for
> non-broken chipsets will be better because there might be no particular
> reasons to check the counter that often.

yeah for the few chipsets i've looked at i haven't seen the problem the 
loop is defending against yet.  or the problem is pretty rare.

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

-dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/