lkml.org 
[lkml]   [2004]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: CONFIG_X86_PM_TIMER is slow
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.347 / U:0.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site