Re: nanosleep() for shorted than schedule slice

[mlelstv%serpens.de@localhost (Michael van Elst)]

bqt%softjar.se@localhost (Johnny Billquist) writes:

>I don't get it. What was the problem with using nanosleep for short 
>usleep's?

usleep is just a wrapper around nanosleep. There is no difference
except that nanosleep accepts higher precision delays.

The kernel computes the number of ticks to sleep, schedules a callout
that will wake the thread up and calls the scheduler to run other
threads in the meantime. The callout is later dispatched by the
clock interrupt.

So you always have to wait for at least one tick, with HZ=100 that's 10ms.

A tickless kernel wouldn't run callouts from the regular clock interrupt
but would use a hires timer to issue interrupts at arbitrary times.
The callout API could then be changed to either accept timespec values or
just fake a much higher HZ value.

-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."