On Mon, 2006-03-06 at 17:35 -0800, john stultz wrote:
> The last time I generated numbers for i386 the patch hit gettimeofday()
> by ~2%, which was the worst case I could generate using the clocksource
> with the lowest overhead (TSC). Most of this was due to some extra u64
> usage and the lack of a generic mul_u64xu32 wrapper. However for this
> cost, you get correct behavior (which I think is *much* more important,
> at least for i386) and nanosecond resolution in clock_gettime().
Ok, so here are some rough numbers calling the various time interfaces
all using the fastest clocksource available (TSC) for timekeeping to
give the best code vs code comparison.
On my p4m laptop w/ idle=poll and clocksource/clock=tsc
mainline vs TOD
gettimeofday(): 106.5%
clock_gettime(CLOCK_MONOTONIC): 99.1%
clock_gettime(CLOCK_REALTIME): 100.1%
So, 6% hit on gtod, the trade off being more robust timekeeping and you
get nanosecond res from clock_gettime for free.
Again, on my laptop w/ idle=poll and clocksource/clock=tsc + minor
performance tweaks of moving cycle_t back to a unsigned long.
mainline vs TOD
gettimeofday(): 103.3%
clock_gettime(CLOCK_MONOTONIC): 98.2%
clock_gettime(CLOCK_REALTIME): 99.0%
Getting closer to calling it a wash.
On an x86-64 AMD server using nopmtimer/clocksource=tsc:
mainline vs TOD
gettimeofday(): 74.2%
clock_gettime(CLOCK_MONOTONIC): 77.4%
clock_gettime(CLOCK_REALTIME): 71.6%
Hmmmm. I'm heading out of town for the weekend in a few moments, and I'd
really like to re-verify those numbers, but yea, that's a 25%
improvement. Might be too good to be true, but that should get Andi's
attention :)
thanks
-john
-
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
