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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
