Messages in this thread | | | Date | Mon, 20 Mar 2006 15:50:48 +0100 | From | Andreas Mohr <> | Subject | Re: gettimeofday order of magnitude slower with pmtimer, which is default |
| |
Hi,
On Mon, Mar 20, 2006 at 01:24:49PM +0100, bert hubert wrote: > Yesterday, together with Zwane, I discovered each gettimeofday call costs me > 4 usec on some boxes and almost nothing on others. We did a fruitless chase > for vsyscall/sysenter happening but the problem turned out to be > CONFIG_X86_PM_TIMER. > > This problem has been discussed before > http://www.ussg.iu.edu/hypermail/linux/kernel/0411.1/2135.html > > Not only is the pm timer slow by design, it also needs to be read multiple > times to work around a bug in certain hardware. I've been realizing this, too, when looking at some oprofile logs. pmtmr reading uses almost 3% CPU time (e.g. P3/700) when idle, and it's similarly problematic when not idle.
I think it's crazy to do a safe tripled readout (with *very* expensive I/O!) of the PM timer unconditionally on *all* systems when only a (albeit not that small) subset of systems is affected by buggy (un-latched) PM timers. I want to improve things there; I can see three ways to do it: a) maintain a blacklist (or probably better a whitelist) of systems that are (not) affected b) detect long-time timer accuracy, then switch to fast readout if timer is verified to be accurate (no white/blacklist needed this way) c) give up on PM timer completely
Any comments on which way and how this could/should be done?
> Would a patch removing the link to EMBEDDED and adding a warning that while > this timer is of high quality, it is slow, be welcome? I don't want to comment on the first part, but adding a note to the Kconfig text would be very useful, I think.
Andreas Mohr - 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/
| |