Messages in this thread | | | Date | Tue, 21 Mar 2006 11:40:56 +1100 | From | kernel@kolivas ... | Subject | Re: 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/
| |