Messages in this thread | | | Subject | Re: [PATCH 1/6] new timeofday core subsystem for -mm (v.B3) | From | john stultz <> | Date | Mon, 20 Jun 2005 14:53:42 -0700 |
| |
On Mon, 2005-06-20 at 14:10 -0400, Lee Revell wrote: > On Mon, 2005-06-20 at 10:09 -0700, john stultz wrote: > > As for gettimefoday() syscall performance, I one had some numbers, but > > I > > would need to re-create them. I'll see if I can grab a slower box and > > give you some hard numbers. > > I ran some tests lately that showed gettimeofday() to be 50x slower than > rdtsc() on my 600Mhz machine. Many userspace apps that need a cheap > high res timer have to use rdtsc now due to the excessive overhead of > gettimeofday(). It would be more correct if these apps could use > gettimeofday() for various reasons (cpufreq and SMP issues).
Yea, I would strongly dissuade anyone from using the rdtsc counter for anything but statistical analysis of code performance.
> So this patch is addressing a real problem. I'd be interested to see if > the performance is good enough to replace rdtsc in these cases.
Yea, honestly I doubt gettimefoday performance will ever be as good as rdtsc. I mean, that's a single instruction vs syscall overhead + hardware clock reading + frequency conversion + ntp adjustment. Its just not a fair comparison.
On the other hand, I bet reading a random 64 bits out of memory is also a bit faster then gettimeofday() as well ;)
I don't mean to promise the world. The point of the patch is not to improve gettimeofday performance, it is to improve the subsystem so it is correct and manageable, so that we have the flexibility to make future improvements (such as High-res Timers, Dynamic Ticks/Variable system timer, and virtualization needs) without impacting performance.
The best payout for gettimeofday performance will probably be in vsyscall implementations such as what x86-64 already has. My new infrastructure also supports this (it had to for x86-64), and I've even got a proof of concept patch for i386 (see the lkml archives for details).
thanks -john
- 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/
| |