lkml.org 
[lkml]   [2005]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 1/6] new timeofday core subsystem for -mm (v.B3)
    From
    Date
    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/

    \
     
     \ /
      Last update: 2005-06-21 00:15    [W:3.010 / U:0.236 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site