[lkml]   [2002]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/3] High-res-timers part 2 (x86 platform code) take 5.1
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

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:30    [W:0.082 / U:2.480 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site