Re: dynamic-hz

[Nish Aravamudan <nish.aravamudan@gmail.com>]

On Tue, 14 Dec 2004 18:15:03 +0100, Andrea Arcangeli <andrea@suse.de> wrote:
> On Tue, Dec 14, 2004 at 08:54:29AM -0800, Nish Aravamudan wrote:
> > Hmm, schedule_timeout(0) working that way is interesting. There is
> > also the option to use schedule_timeout(MAX_SCHEDULE_TIMEOUT) which
> > should sleep indefinitely (depending of course on the conditions of
> > the state). Oh but I think I understand what you're saying... the
> > driver needs to sleep indefinitely in total (potentially), but needs
> > to be able to return quite often (like yield() used to) so they could
> > check a condition...
> >
> > Thanks for the input!
> 
> what do you mean like yield() used to? yield() is still there in latest
> 2.6, just call yield() and you'll get the same effect of sched_yield in
> userspace. yields in the kernel are a bad thing though (they usually
> mean code is not well written, code should be event driven not polled
> driven).

Sorry for my lack of clarity :) I was referring more to the second
part of what you said, that the "meaning" of yield() changed for 2.6
and thus shouldn't be used to wait for short times (see kerneljanitors
TODO reference from Matthew Wilcox (search for yield in page):
http://www.kerneljanitors.org/TODO).
 
> Note that __set_current_state(..); schedule_timeout(0) is not like
> yield. yield will return immediatly if it's the only task running. A
> yielding loop will consume all available cpu, while the
> schedule_timeout(0) will wait less than 1/HZ sec. But really
> schedule_timeout(0) makes little sense, either use schedule_timeout(1)
> and explicitly wait 1msec, or use yield. schedule_timeout(0) just
> happens to work because the timer code has to approximate for excess and
> it will wait for the next timer irq for timeouts <= 0 and it will wait
> for two ticks for timeouts == 1 etc...

>From the context of the TODO, it seems yield() and schedule_timeout()
should not be considered alternatives for each other. Maybe someone
can clarify?

> I guess we could change schedule_timeout() to WARN_ON if 0 is being
> passed to it.

I will see if anyone is actually calling with 0 -- I don't remember
seeing this for my previous sets of patches, but it may happen if HZ
changes in value.

-Nish