[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.021 / U:6.024 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site