[lkml]   [1996]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Sleeping on the job
> > 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
Linux Plug-and-Play Project

 \ /
  Last update: 2005-03-22 13:37    [W:0.023 / U:1.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site