public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: George Anzinger <george@mvista.com>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Tony Lindgren <tony@atomide.com>, Pavel Machek <pavel@suse.cz>,
	john stultz <johnstul@us.ibm.com>,
	Zwane Mwaikambo <zwane@arm.linux.org.uk>,
	Con Kolivas <kernel@kolivas.org>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dynamic tick patch
Date: Wed, 19 Jan 2005 14:59:20 -0800	[thread overview]
Message-ID: <41EEE648.2010309@mvista.com> (raw)
In-Reply-To: <20050119174858.GB12647@dualathlon.random>

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/


  parent reply	other threads:[~2005-01-19 22:59 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-19  0:05 [PATCH] dynamic tick patch Tony Lindgren
2005-01-19  0:22 ` Lee Revell
2005-01-19  1:04   ` Tony Lindgren
2005-01-19  4:21 ` Benjamin Herrenschmidt
2005-01-19  5:07   ` Tony Lindgren
2005-01-19  5:21     ` Tony Lindgren
2005-01-19  5:44       ` Benjamin Herrenschmidt
2005-01-19  6:26         ` Tony Lindgren
2005-01-19  9:45           ` Pavel Machek
2005-01-19  5:28     ` Benjamin Herrenschmidt
2005-01-19  6:37       ` Tony Lindgren
2005-01-19  7:08         ` Benjamin Herrenschmidt
2005-01-19  7:31           ` Tony Lindgren
2005-01-19 14:11       ` Stephen Frost
2005-01-19 17:17         ` Tony Lindgren
     [not found]         ` <OFDC470564.D4624EB3-ON41256F8E.00512848-41256F8E.005428CC@de.ibm.com>
2005-01-19 17:37           ` Tony Lindgren
2005-01-19  9:43 ` Pavel Machek
2005-01-19 17:13   ` Tony Lindgren
2005-01-19 17:48     ` Andrea Arcangeli
2005-01-19 18:19       ` Tony Lindgren
2005-01-19 19:12         ` Andrea Arcangeli
2005-01-19 19:17           ` Tony Lindgren
2005-01-19 19:34             ` Tony Lindgren
2005-01-19 22:42               ` Andrea Arcangeli
2005-01-19 22:59       ` George Anzinger [this message]
2005-01-19 23:17         ` Tony Lindgren
2005-01-20  0:24           ` George Anzinger
2005-01-20  8:04             ` Tony Lindgren
2005-01-20 23:10               ` George Anzinger
2005-01-21 17:35                 ` Tony Lindgren
2005-01-21 20:23                   ` George Anzinger
2005-01-19 23:26         ` Thomas Gleixner
2005-01-19 23:45           ` john stultz
2005-01-20  5:56             ` Thomas Gleixner
2005-01-20  0:39           ` George Anzinger
2005-01-20  3:15         ` Valdis.Kletnieks
2005-01-19 11:36 ` Pavel Machek
2005-01-19 17:11   ` Tony Lindgren
2005-01-19 17:30     ` Arjan van de Ven
2005-01-19 17:41       ` Tony Lindgren
2005-01-19 22:06     ` Pavel Machek
2005-01-19 23:08       ` Tony Lindgren
2005-01-19 23:46         ` Pavel Machek
2005-01-19 23:53           ` Tony Lindgren
2005-01-19 23:59         ` Pavel Machek
2005-01-20  0:07           ` Tony Lindgren
2005-01-20  0:44             ` Pavel Machek
2005-01-20  0:54             ` Pavel Machek
2005-01-20  7:39               ` Tony Lindgren
2005-01-19 22:20     ` Pavel Machek
2005-01-20  4:02 ` Zwane Mwaikambo
2005-01-21 17:48   ` Tony Lindgren
2005-01-21 18:27     ` Zwane Mwaikambo
2005-01-21 18:38       ` Tony Lindgren
2005-01-21 18:54       ` Pavel Machek
2005-01-21 21:23         ` Zwane Mwaikambo
2005-01-21 21:29           ` Pavel Machek
2005-01-21 20:25       ` George Anzinger
2005-01-21 21:38         ` Zwane Mwaikambo
2005-01-22  7:24           ` George Anzinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41EEE648.2010309@mvista.com \
    --to=george@mvista.com \
    --cc=andrea@suse.de \
    --cc=johnstul@us.ibm.com \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@suse.cz \
    --cc=schwidefsky@de.ibm.com \
    --cc=tony@atomide.com \
    --cc=zwane@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox