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).
next prev 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).