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

[Ingo Molnar]

* Linus Torvalds <torvalds@xxxxxxxx> wrote:

> I suspect that it is impractical to reprogram the PIT on a very fine 
> granularity.

yes - reprogramming the PIT can take up to 10 usecs even on recent PCs.  
(in fact the cost is pretty much system-independent due to PIO.) On 
modern, PIT-less timesources (e.g. HPET) it can be faster.

> Btw, if somebody really gets excited about all this, let me say (once 
> again) what I think might be an acceptable situation.
> 
> First off, I'm _not_ a believer in "sub-HZ ticks". Quite the reverse. 
> I think we should have HZ be some high value, but we would _slow_down_ 
> the tick when not needed, and count by 2's, 3's or even 10's when 
> there's not a lot going on.

i think that would be an acceptable solution for high-precision timers, 
as long as two other problems are solved too:

 - there are real-time applications (robotic environments: fast rotating
   tools, media and mobile/phone applications, etc.) that want 10
   usecs precision. If such users increased HZ to 100,000 or even
   1000,000, the current timer implementation would start to creek: e.g.
   jiffies on 32-bit systems would wrap around in 11 hours or 1.1 hours.
   (To solve this cleanly, pretty much the only solution seems to be to
   increase the timeout to a 64 bit value. A non-issue for 64-bit
   systems, that's why i think we could eventually look at this 
   possibility, once all the other problems are hashed out.)

 - at very high HZ values the clustering of e.g. network timers is lost, 
   creating an artificially high number of timer interrupts. So likely 
   we'd still need some way to 'blur' timeouts and to round e.g. network 
   timers to the next 1 msec or 500 usecs boundary, to cluster up timers 
   for bulk processing. But in any case, such a solution does not sound 
   nearly as messy as the sub-jiffies method.

if the 'high precision' uses are not addressed [*] i fear the whole HRT 
game starts again: embedded folks trying to standardize on Linux for 
everything [**] will want HRT timers and will do addons and sub-jiffy 
approaches [***], and will push for inclusion. I think we could as well 
solve this whole problem area by making ridiculously high HZ values 
practical too!

	Ingo

[*]  there's also a third problem: timer prioritization. It's not 
     necessarily a problem the upstream kernel should care about, but 
     it's a problem for things that try to offer hard-real-time, like 
     PREEMPT_RT: HRT timers need to be prioritizable. If e.g. the system 
     is soaked handling network timers, it should still be possible for 
     that single mega-important HRT timer to run and wake up the 
     mega-high-priority RT task that will preempt all network activity 
     within 10 usecs worst-case. The sub-jiffies approach does this 
     prioritization in a natural way, because there HRT timers are 
     separate, so the prioritization of them is easy. With the grand 
     unified 'big HZ' scheme the HRT folks would have to implement a 
     mechanism to split off highprio timers from the stream of normal 
     timers. ]

[**] having high precision is also a perception and uniformity of 
     platform issue: most embedded developers will find 500 usecs 
     precision good enough for most uses, but it does not 'sound' good 
     enough, and there's no easy way out either. So _if_ there's the 
     occasional need for higher precision they'll have no easy solution 
     for Linux, and this prevents them from standardizing on Linux for 
    _everything_.


[***]
   a side-thought about sub-jiffies: the biggest conceptual problem 
   the sub-jiffy method has is the sorting needed when timers move from 
   the jiffy bucket into the HRT list which doesnt scale - but this is 
   really a HRT-timers-internal problem.  It could be further improved 
   by e.g.  dividing the last jiffy up into say 10 usec buckets - with a 
   1msec jiffy clock that's 100 buckets, and having a bitmap to see 
   which bucket is active. Then the 'get the next timer' act becomes a 
   matter of searching the bitmap for the next bit set - at pretty much 
   constant overhead. Even a 1 usec precision would mean only 1000 
   buckets for the last jiffy, with 1000 bits (128 bytes) to search, 
   still quite ok. But, in any case, it would be nice to avoid the 
   "conceptual dualness" of the HRT patch.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/