Messages in this thread |  | | Subject | Re: Sleeping on the job | Date | Fri, 17 May 1996 01:03:03 -0400 (EDT) | From | "Andrew E. Mileski" <> |
| |
> > Yes, I know this too. To help you help me, FORGET I ever mentioned > > how long the delay needs to be. > > you're the one who was self-deprecating in your original query.
That's because I'm a moron compared to some of the BRILLIANT minds that work on the kernel. Obviously I failed to phrase my question well, but we are going in the direction I need. Thanks! :-)
> > Now, in a situation where there > > are several small delays that can add up to a _BIG_ amount of overall > > time (say a few seconds), and all of this is on a single kernel call, > > what should I do? > > sleep, obviously. the only other alternative is to spin, wasting cycles.
Not so obvious to me - that's why I was asking. I wasn't 100% sure. (I understand some of the kernel code, but far from all of it) I was fairly certain it was a bad Idea on a SMP machine though.
Is there something I can TEST before committing to a sleep? Example: if the slice has just begun there may be plenty of time (up to 10ms) for short delays before a sleep would be "a real good idea".
> > As the individual delays are small, it is possible to do some processing > > before starting the next delay cycle. The individual delays are not the > > problem, the combined affect of all of them _could_ be a problem (I guess). > > you can either use the current scheduler to sleep, presumably altering HZ > to give you better granularity. or you can reimplement the scheduler using > arbitrary delays (which need not involve the RTC, btw).
Okay, a silly question: how do I properly sleep and get woken after a specific amount of time? This I don't know :-)
Thanks for your helpful comments.
-- Andrew E. Mileski mailto:aem@ott.hookup.net http://www.redhat.com/~aem/ Linux Plug-and-Play Project http://www.redhat.com/pnp/
|  |