[lkml]   [2006]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: gettimeofday order of magnitude slower with pmtimer, which is default
Quoting OGAWA Hirofumi <>:

> Con Kolivas <> writes:
> > The pm timer is very fast when the timer is latched and that strange loop
> uses
> > hardly any cpu time. The same can't be said about the unlatched timer case
> > where absurd amounts of cpu seem the norm. You have a catch 22 situation if
> > you depend on the accuracy of the pm timer only to end up wasting time
> trying
> > to actually use that timer.
> Actually, pmtmr not seems very fast, rather it's slow like usual I/O port.

What I mean is that I've seen profiles of the worst (from Andi) showing up to 5%
cpu time on some workloads! That's a heck of a lot slower than when it's

> is about 1us.
> And the following is test of gettimeofday(). Probably, we need a patch.
> Umm....
> 2.6.16 (pmtmr)
> Simple gettimeofday: 3.6532 microseconds

> 2.6.16+patch (pmtmr)
> Simple gettimeofday: 1.4582 microseconds

Looks well worth it

> 2.6.16 (tsc)
> Simple gettimeofday: 0.4037 microseconds

> Signed-off-by: OGAWA Hirofumi <>


> + if (unlikely(pmtmr_need_workaround)) {

I would not put this in an unlikely because on the machines where
pmtmr_need_workaround is true this will always be true.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-03-21 02:52    [W:0.050 / U:9.652 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site