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