lkml.org 
[lkml]   [2006]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: gettimeofday order of magnitude slower with pmtimer, which is default
Quoting OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>:

> Con Kolivas <kernel@kolivas.org> 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
latched.

> 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 <hirofumi@mail.parknet.co.jp>

Thanks!

> + 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.

Cheers,
Con

-
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: 2006-03-21 02:52    [W:0.066 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site