Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2005-07-14 at 09:37 -0700, Linus Torvalds wrote:
> 
> On Thu, 14 Jul 2005, Vojtech Pavlik wrote:
> >  
> > A note on the relaive timer API: There needs to be a way to say
> > "x milliseconds from the time this timer should have triggered" instead
> > of "x milliseconds from now", to avoid skew in timers that try to be
> > strictly periodic.
> 
> I disagree.
> 
> There should be an _absolute_ interface, and a driver that wants that 
> should just have calculated when in time the timeout finishes - and then 
> keep on using the absolute value.
> 
> Btw, this is exactly why the jiffy-based thing is _good_. The kernel 
> timers _are_ absolute, and you make them relative by adding "jiffies".
> 
> The fact is, the current timers are better than people give them credit 
> for, and converting them away from a jiffies-based interface (to a 
> usleep-like one) is STUPID.

Yes, I strongly agree that absolute references are required in order to
avoid the accumulating time error that can happen when folks use
relative interfaces alone. 

That said, I still think there is a benefit to moving away from jiffies
and using absolute time units. Now keep your badder in control for just
a second, let me try to explain myself :)

> There's absolutely nothing wrong with "jiffies", and anybody who thinks 
> that
> 
> 	msleep(20);
> 
> is fundamentally better than
> 
> 	timeout = jiffies + HZ/50;
> 
> just doesn't realize that the latter is a bit more complicated exactly 
> because the latter is a hell of a lot more POWERFUL. Trying to get rid of 
> jiffies for some religious reason is _stupid_.


Agreed, but we preserve the same correctness if we do something like:
	now_ns = do_monotonic_clock()
	timeout_ns = now_ns + 20000000;

And I'd argue we get something even more powerful. First, we have
something that is more easily understandable because we're working with
units people do not have to convert. Secondly we have a fixed point in
TIME rather then ticks, which allows us to avoid all the issues caused
by lost timer interrupts and the fact that (jiffies * HZ) != (xtime +
wall_to_monotonic).

Again, I agree that that it is necessary to keep absolute units similar
to what you posted about setting HZ to 2000 and just varying the
interrupt frequency as needed. Only rather then keeping some ticks as
our absolute unit, why not nanoseconds? Then we can make changes to the
interrupt frequency without affecting our absolute references.

Nish has some code, which I hope he'll be sending out shortly that does
just this, converting the soft-timer subsystem to use absolute time
instead of ticks for expiration. I feel it both simplifies the code and
makes it easier to changing the timer interrupt frequency while the
system is running.

We'll also be talking more about it at OLS, where apparently I may have
to hide behind plastic sheeting. :)

thanks
-john

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux