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

From: john stultz (johnstul_at_us.ibm.com)
Date: 06/21/05

  • Next message: Adrian Bunk: "[2.6 patch] drivers/scsi/aic7xxx/: possible cleanups" 
    To: Roman Zippel <zippel@linux-m68k.org>
Date:	Mon, 20 Jun 2005 16:55:34 -0700

    On Tue, 2005-06-21 at 00:05 +0200, Roman Zippel wrote:
    > Hi,
    >
    > On Mon, 20 Jun 2005, john stultz wrote:
    >
    > > > I see lots of new u64 variables. I'm especially interested how this code
    > > > scales down to small and slow machines, where such a precision is absolute
    > > > overkill. How do these patches change current and possibly common time
    > > > operations?
    > >
    > >
    > > Hey Roman,
    > > That's a good issue to bring up. With regards to the timeofday
    > > infrastructure, there are two performance concerns (though let me know
    > > if I'm forgetting something):
    >
    > You don't really answer the core question, why do you change everything to
    > nanoseconds and 64bit values?

    Well, for a reasonable range of timesource frequencies and interval
    lengths, the cycle values needs to be 64 bits wide and the mult/shift
    operation to convert cycles to time is going to need to done with 64
    bits.

    Since xtime is currently a timespec, we already keep nanosecond
    precision using 64 bits. It was then just a question of how complicated
    is it to do the manipulations with timespecs vs flat 64 bits worth of
    nanoseconds. Nanoseconds made the design cleaner, so I went with them
    keeping the option to optimize in the future when real issues arose.

    > > On smaller systems, timer interrupt processing is a concern, with the
    > > shift to HZ=1000, we got a number of complaints from folks w/ old 486s
    > > where time would drift due lost ticks. This would happen when something
    > > (usually IDE in PIO mode) would disable interrupts and they would miss a
    > > ton of timer interrupts. Also the impact of running the timekeeping code
    > > 10x more frequently was seen in a number of cases.
    > >
    > > With the new infrastructure, timekeeping is all done via a soft-timer
    > > outside of interrupt context. In fact, the timekeeping soft-timer is
    > > setup to run every 50ms instead of every ms. This should help overall
    > > performance on slower systems using high HZ values.
    >
    > With -mm you can now choose the HZ value, so that's not really the
    > problem anymore. A lot of archs even never changed to a higher HZ value.
    > So now I still like to know how does the complexity change compared to the
    > old code?

    Well, even if it is less of a concern with lower HZ values, my code
    should still reduce the interrupt overhead for those who would like to
    have higher HZ values to improve latency. (Although until I have
    numbers, its all just talk. :)

    > > 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. The gettimeofday() path is fairly
    > > streamlined and should be pretty straight forward in the patch (see
    > > kernel/timeofday.c), so let me know if you have specific concerns.
    > >
    > > There will probably be a bit of a drop, but I have some ideas for
    > > cacheing a precomputed timeval in the timekeeping soft-timer if its a
    > > serious issue.
    >
    > Well, AFAICT on slower machines (older and embedded stuff) it's a serious
    > issue. The current code calculates the timeval with some simple 32bit
    > calculations. Your code introduces the nsec step, which means several
    > 64bit calculations and suddenly the overhead explodes on some machines.
    >
    > As m68k maintainer I see no reason to ever switch to your new code, which
    > might leave you with the dilemma having to maintain two versions of the
    > timer code. What reason could I have to switch to the new timer code?
    >
    > I had no problems with a little more overhead, like a _few_ more 64bit
    > operations per second (and preferably add/shifts), but I'm not really
    > enthusiastic about the new code. Why don't you keep the main part 32 bits
    > (or long)? What's wrong with using timeval or timespec?

    Well, I think the only overhead to be worried with is just in
    gettimeofday(), but let me get some hard numbers to show that. I've
    already implemented some optimized caching for x86-64's vsyscall-gtod
    implementation, so let me also try to make an arch generic version and
    see if I cannot settle your concerns.

    > I like the concept of the a time source in your patch. m68k already uses a
    > number of timer related callbacks into machine specific code. If I could
    > replace that with a timer driver, I'd be really happy. OTOH if it requires
    > several expensive conversion between different time formats, I rather keep
    > the current code.

    Thanks, I really appreciate your review and feedback. I very much want
    this to be a solution everyone can be happy (or at least indifferent)
    with.

    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/

  • Next message: Adrian Bunk: "[2.6 patch] drivers/scsi/aic7xxx/: possible cleanups"

    Relevant Pages

    • [PATCH 7/9] introduce ktime_t
      ... the resolution of the specified timer shall be rounded up to the larger ... * internal representation of time values in scalar nanoseconds. ... +static inline ktime_t ktime_add ... +static inline struct timespec ktime_to_timespec ...
      (Linux-Kernel)
    • Re: [RFC][PATCH] new timeofday core subsystem (v.A0)
      ... >> one in the timer code is the real issue. ... > work with nanoseconds. ... I see that as just a problem of programming the timer interrupt ... > adjust it for drift over time. ...
      (Linux-Kernel)
    • [patch 14/33] xen: xen time implementation
      ... Xen maintains a base clock which measures nanoseconds since system ... the kernel is a simple clocksource which simply returns the current ... Xen also provides a simple timer mechanism, ... We don't care about or use this tick, ...
      (Linux-Kernel)
    • Re: need time in nano seconds
      ... When an interface claims to offer nanosecond time information, ... not any more *accurate* than a *microsecond* timer could be. ... I suspect that people write APIs in terms of nanoseconds so that, ...
      (Debian-User)