linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: mbs <mbs@mc.com>
To: "Randy.Dunlap" <rddunlap@osdl.org>,
	Linus Torvalds <torvalds@transmeta.com>
Cc: george anzinger <george@mvista.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] High-res-timers part 2 (x86 platform code) take 5.1
Date: Fri, 18 Oct 2002 09:11:21 -0400	[thread overview]
Message-ID: <200210181305.JAA28085@mc.com> (raw)
In-Reply-To: <Pine.LNX.4.33L2.0210171453050.2499-100000@dragon.pdx.osdl.net>

On Thursday 17 October 2002 17:54, Randy.Dunlap wrote:
> On Wed, 9 Oct 2002, Linus Torvalds wrote:
> | On Wed, 9 Oct 2002, george anzinger wrote:
> | > This patch, in conjunction with the "core" high-res-timers
> | > patch implements high resolution timers on the i386
> | > platforms.
> |
> | I really don't get the notion of partial ticks, and quite frankly, this
> | isn't going into my tree until some major distribution kicks me in the
> | head and explains to me why the hell we have partial ticks instead of
> | just making the ticks shorter.
> | -

because just making ticks shorter/more frequent just increases timer overhead 
all the time whether you are actually doing anything requiring it or not. 
this is a big waste of cpu cycles.

using the partial tick method put forward by george, you only pay the price 
for higher resolution timers WHEN YOU WANT TO.

most things that want say 1usec precision dont want to do something EVERY us, 
just something every now and then with 1us precision.  things like programs 
that want to block for a 350 usec. but waiting 10 or even 1 msec would be too 
long. 

the timer overhead using fixed interval timers (as you suggest) to support 
that occaisional 350 usec block would eat too much cpu to be practical.

increasing timer frequency penalizes ALL users/processes with increased timer 
overhead all the time for the benefit of the small number of tasks that need 
better resolution.  the sub-jiffie/partial tick model only pays that price 
when there is an actual timed event that needs to occur at that higher 
resolution and the rest of the time the timer overhead remains as it is today 
(which to my mind is 10 times what it needs to be, but that is an argument 
for another day)

embedded systems in particular need higher resolution and these types of 
systems are precisely the systems that can't afford to multiply their timer 
overhead by a factor of 10 or more (as increasing HZ to 1000 does).



  parent reply	other threads:[~2002-10-18 12:59 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-09 22:47 [PATCH 2/3] High-res-timers part 2 (x86 platform code) take 5.1 george anzinger
2002-10-09 23:14 ` Linus Torvalds
2002-10-09 23:42   ` george anzinger
2002-10-10 15:03     ` Eric W. Biederman
2002-10-10 15:45       ` george anzinger
2002-10-10 15:54     ` Oliver Xymoron
2002-10-10 16:24       ` george anzinger
2002-10-10 17:04         ` Oliver Xymoron
2002-10-10 17:47           ` george anzinger
2002-10-13 10:46   ` Ingo Adlung
2002-10-14  7:18     ` Vojtech Pavlik
2002-10-14 22:17       ` Pavel Machek
2002-10-15  7:13         ` Vojtech Pavlik
2002-10-15 21:45           ` george anzinger
2002-10-17 21:54   ` Randy.Dunlap
2002-10-17 22:11     ` Robert Love
2002-10-18 13:11     ` mbs [this message]
2002-10-10  0:50 Dan Kegel
2002-10-10  1:33 ` Ben Greear
2002-10-10  3:55 ` Jeff Dike
2002-10-10  3:32   ` Dan Kegel
2002-10-10 12:34 ` mbs
2002-10-12 22:03 Jim Houston
2002-10-14  6:50 ` Ulrich Windl
2002-10-15 22:03   ` george anzinger
2002-10-19  1:02 Brad Bozarth

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=200210181305.JAA28085@mc.com \
    --to=mbs@mc.com \
    --cc=george@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rddunlap@osdl.org \
    --cc=torvalds@transmeta.com \
    /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;
as well as URLs for NNTP newsgroup(s).