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

[Christoph Lameter <christoph@lameter.com>]

On Thu, 14 Jul 2005, Lee Revell wrote:

> On Thu, 2005-07-14 at 10:38 +0200, Ingo Molnar wrote:
> >  - 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.)
> > 
> 
> Those types of systems will not be 64 bit for many, many years, if
> ever...

Linux can already provide a response time within < 3 usecs from user space 
using f.e. the Altix RTC driver which can generate an interrupt that then 
sends a signal to an application. The Altix RTC clock is supported via POSIX
timer syscalls and can be accessed using CLOCK_SGI_CYCLE. This has been 
available in Linux since last fall and events can be specified with 50 
nanoseconds accurary.

Other clock sources like  HPET could do the same if someone would be 
willing to provide the hookup to the posix layer.

I doubt that increasing the timer frequency is the way to go to solve 
these issues. HZ should be as low as possible and we should strive for a 
tickless system.