> > there's no mechanism to sleep for less than a scheduler quantum;
> > that's 10 ms in normal x86 linux.
>
> Ya, I know that. But do I need to worry about delays that are over
> 10ms (possibly a few seconds) in kernel code? If so, what and how
> should I handle it?
any event that has a "slow interrupt" handler can wake up a process (thus
implement high precision sleeping). One example is the RTC device, you can
read it, and you get data off it with a certain frequency. (that frequency
ranges from 8 khz to 2 hz i think).
So if your process has sufficiently high priority and it's reading
/dev/rtc, then you can sleep for intervals as low as 122 usecs (8192 Hz).
And it's purely interrupt driven, no polling done.
sleeping >within< the kernel is much more problematic, and current state
of the art AFAIK is that such activities should be moved off into
userspace. kflushd, kswapd and bdflush are such examples IMHO.
-- mingo