Messages in this thread | | | Date | Thu, 11 Nov 2004 23:43:14 -0800 (PST) | From | dean gaudet <> | Subject | Re: 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/
| |