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/