Re: [PATCH 1/6] new timeofday core subsystem for -mm (v.B3)

[john stultz <johnstul@us.ibm.com>]

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