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

From: Roman Zippel (zippel_at_linux-m68k.org)
Date: 06/21/05

  • Next message: domen_at_coderock.org: "[patch 4/4] DCO: use IANA-reserved second level domain name" 
    Date:	Tue, 21 Jun 2005 00:05:34 +0200 (CEST)
To: john stultz <johnstul@us.ibm.com>

    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?

    > 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?

    > 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?

    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.

    bye, Roman
    -
    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: domen_at_coderock.org: "[patch 4/4] DCO: use IANA-reserved second level domain name"

    Relevant Pages

    • Re: do pop up boxes stop all events?
      ... You can "get out of there" in just a few microseconds and the next event will still not occur on the next 10 millisecond interval on most machines. ... The fact is that the underlying sytem which triggers the VB Timer does not really get a very high priority and the OS doesn't really consider such timings to be important. ... Private Declare Function timeBeginPeriod _ ... Private Sub Form_Unload ...
      (microsoft.public.vb.general.discussion)
    • Re: [patch 6/6] x86: add c1e aware idle function
      ... This excludes those machines from high ... To work nicely with C1E enabled machines we use a separate idle ... This allows us to do timer broadcasting ... Does the boot CPU ...
      (Linux-Kernel)
    • Re: 50 hz timer motor
      ... on the Brandt BR1000) where the cycling motor modules, ... On that type of timer, the timer motor is usually wired through a ... > part of the fill - and on some machines, the initial part of the water ... The pressostat (water level switch) and/or the thermostats are ...
      (sci.electronics.repair)
    • Re: [patch 6/6] x86: add c1e aware idle function
      ... when the CPU goes into C1E. ... This excludes those machines from high ... This allows us to do timer broadcasting ... Entering idle is quite a common operation, ...
      (Linux-Kernel)
    • Re: [patch 6/6] x86: add c1e aware idle function
      ... when the CPU goes into C1E. ... This excludes those machines from high ... This allows us to do timer broadcasting ... Entering idle is quite a common operation, ...
      (Linux-Kernel)