100 Hz means your minimum scheduling interval is 10 milliseconds,
and *sleep() guarantees *at least* parametrized amount of sleep,
not *exactly* parametrized amount of sleep.
There are also odd reasons in timer code, why HZ of power of two
is best, instead of some "nice" 100 or 1000 ...
(Jiffies to 'struct timeval', I vaguely recall..)
> x86 also takes 10 or more microseconds to service an interrupt (it is
> said because of motherboards not the CPU itself).
How long IRQ processing takes *does* depend upon used chips.
When the IRQ-controller is in modern core-logic chipsets, it
does not need to behave like its ancient ISA-bus-bound precursors.
> Do you really want to spend 1% CPU servicing timer interrupts just so
> _occasionally_ a program can get a short sleep to 2ms accuracy?
>
> I'd rather see:
>
> - slow HZ -- low interrupt load
> - accurate timers on demand
> - *precise* timing with accuracy of hardware
>
> [ And then I'd like to see the accurate timers used for polling network
> cards under load :-) ]
RTC based interrupts ? Highly accurate periodic interrupts,
not re-sceduling based "regular by luck"...
> -- Jamie
/Matti Aarnio <matti.aarnio@sonera.fi>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/