Messages in this thread |  | | Date | Fri, 17 May 1996 19:43:56 +0100 (GMT+0100) | From | Ingo Molnar <> | Subject | Re: Sleeping on the job |
| |
On Fri, 17 May 1996, Andrew E. Mileski wrote:
> > 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
|  |