Re: [PATCH] dynamic tick patch

From: George Anzinger (george_at_mvista.com)
Date: 01/19/05

  • Next message: Greg KH: "Re: kobject_uevent.c moved to kernel connector." 
    Date:	Wed, 19 Jan 2005 14:59:20 -0800
To: Andrea Arcangeli <andrea@suse.de>

    Andrea Arcangeli wrote:
    > On Wed, Jan 19, 2005 at 09:13:23AM -0800, Tony Lindgren wrote:
    >
    >>HZ=100 does not allow improving the idle loop much further
    >>from what we have. We should be able to take advantage of the
    >>longer idle/sleep periods inbetween the skipped ticks.
    >
    >
    > OTOH servers aren't just doing idle power saving, if you're computing
    > wasting 1% of your cpu isn't always desiderable.
    >
    > You'd need to trap into add_timer to make it a truly dynamic timer, only
    > then it would obsolete the HZ=100. So if there's no timer you run at
    > HZ=100, while if there's some timer pending in the next 10 timer queues
    > you run at HZ=1000.
    >
    > The main problem I can see with your patch is the accuracy issue with
    > the system time. I couldn't fix the algorithm you're depending on to get
    > accurate system time, and I can guarantee such algorithm never worked
    > accurately here and worst of all it doesn't printk anything (which is
    > why it doesn't printk for your patch), so you only see system time go in
    > the future at an excessive rate (minutes per hour IIRC).
    >
    > Pavel posted the cli/sti script, that should allow to reproduce the
    > inaccuracy of the algorithm. I had to set HZ=100 by hand to workaround
    > the usb modem irq latency that is about 3/4 msec.
    >
    > Once in a while such algorithm overstates the number of ticks that have
    > been missed, and so the system time goes 1msec in the future when that
    > happens. I still suspect there might be a bug in such code though.
    > There's an unfixable window between the latch read and the tsc
    > read where an error can happen, but as long as the window is below
    > 0.5msec, it should always be possible to regenerate the accurate timing
    > with the current algo, but in practice it fails to be accurate...
    > -
    I don't think you will ever get good time if you EVER reprogramm the PIT. That
    is why the VST patch on sourceforge does NOT touch the PIT, it only turns off
    the interrupt by interrupting the interrupt path (not changing the PIT). This
    allows the PIT to be the "gold standard" in time that it is designed to be. The
    wake up interrupt, then needs to come from an independent timer. My patch
    requires a local APIC for this. Patch is available at
    http://sourceforge.net/projects/high-res-timers/ 

    -- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
-
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: Greg KH: "Re: kobject_uevent.c moved to kernel connector."

    Relevant Pages

    • Re: [PATCH] dynamic tick patch
      ... > I don't think you will ever get good time if you EVER reprogramm the PIT. ... > turns off the interrupt by interrupting the interrupt path (not changing ... My patch requires a local APIC for this. ... It should not matter where the timer interrupt comes from, ...
      (Linux-Kernel)
    • Re: [PATCH] dynamic tick patch
      ... >>I don't think you will ever get good time if you EVER reprogramm the PIT. ... >>turns off the interrupt by interrupting the interrupt path (not changing ... >>independent timer. ... My patch requires a local APIC for this. ...
      (Linux-Kernel)
    • Re: Microstate Accounting for 2.6.11
      ... a tick is added to either system time or user ... Thus in an unpacthed kernel ... >> service an interrupt, etc., etc. ... Andrew> Why does the kernel need this feature? ...
      (Linux-Kernel)
    • Re: [PATCH] RealTimeSync Patch
      ... >> Looking at the archives I see that a an intel patch ... setting the system time until the actual RTC ... The forum, of late, has been taking a different approach. ... While the forum has a few patches we want to push ...
      (Linux-Kernel)
    • Re: [PATCH 0/2] convert mmap_sem to a scalable rw_mutex
      ... reduction in system time on ebizzy runs (without the MADV_FREE patch). ... This 6% runtime reduction on a 2-way box will i suspect get ... that without doing a mass API changeover, by embedding struct rw_mutex ...
      (Linux-Kernel)