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

[john stultz <johnstul@us.ibm.com>]

On Thu, 2005-07-14 at 13:13 -0700, Linus Torvalds wrote:
> 
> On Thu, 14 Jul 2005, john stultz wrote:
> > 
> > We'll I'd probably put it as: "they do care about absolute time, but
> > they do not care about ticks or timer interrupt frequency"
> 
> Well, the thing is, you have to count time some sane way.
> 
> You can do it by having very expensive data structures that say "real
> time", but then you have some serious confusion when it comes to things
> like whether it's wallclock time (which might have shifts and other
> interesting issues) or some "virtual cpu time". You also end up having a
> much much more expensive interface, ie "time_after()" ends up being a much
> more complicated test.

I think you might be mis-characterizing Nish's and my idea. To me it
sounds very close to what you are suggesting w/ the HZ=2k idea.

> So the _sane_ way to do timeouts is to define an _arbitrary_ clock that is 
> just an integer counter. None of this "nanoseconds + full seconds" crap. 
> None of this stupid confusion with "real time". You select something that 
> is conceptually _clearly_ somethign else, and that will never get confused 
> when root sets the time backwards or anything like that.

But confusion is the problem we have now. 

People think in time, so they try to convert it into jiffies using HZ,
but then they're surprised when things happen early since the interrupt
freq isn't quite HZ but ACTHZ. Then if you fix that, you still have the
issue that if they use clock_gettime(CLOCK_MONOTONIC) to measure your
timer request it may still be early because jiffies aren't NTP adjusted.

We're not suggesting using timespecs for timers internally, just
do_monotonic_clock() which in Nish's patch returns 64 bits of
nanoseconds since the system booted and doesn't go backwards.

> In other words, you select the thing we call "jiffies".

In Nish's patch, do_monotonic_clock() is used in almost exactly the same
way as jiffies is used. 

Imagine HZ is a billion we have perfect timer hardware (which increments
jiffies exactly each nanosecond)and replace jiffies w/
do_monotonic_clock(). 

That's effectively what you get only without having the timer interrupt
go off a billion times a second. Instead, the timer interrupt can go off
at whatever frequency and soft-timers don't have to care. All interrupt
frequency changes is worse case latency.
 

> Face it, it is just _superior_ to the alternatives. The alternative is to
> have some "fake time" aka "struct timespec", and always have to worry
> about normalization and complicated comparisons, and using more memory 
> too, btw.
>
> There is no way to avoid having some kind of counter to specify time.  
> NONE. The only choice is what you base your notion of time on, and how you
> represent it. Do you represent it as two separate counters and try to make
> it look like "fractions of seconds", or do you represent it as a single
> counter, and make it look like "ticks".

I agree we have to keep time somehow, but we already do and we already
keep nanosecond precision. So why don't we just use it instead of some
low-res interrupt counter?

> And the single counter is _simpler_. The alternatives have absolutely 
> _zero_ upsides. Name _one_. 

In my mind, consistency. 

I mean, if I understand your suggestion w/ HZ=2k. Effectively you are
just redefining jiffies to be some fixed unit (effectively 500
microseconds). Then when timer interrupt arrive at some frequency lower
then 2kHZ you have to add more then 500usecs to jiffies. Right?

This is what we already do for timekeeping. The only difference is that
timekeeping deals with the HZ/ACTHZ issue and NTP adjustments and we
keep nanosecond precision.

thanks
-john