Re: dynamic-hz

[linux-os]

On Tue, 14 Dec 2004, Andrea Arcangeli 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).

Yield used to not show a spin in `top`.  Also, contrary to
"popular" opinion, not all events are accompanied by interrupts.
If they where, I'd gladly use one of the sleep_on* functions.

For instance, I need to erase NVRAM (Flash). Then I need to
program each byte. Waiting for the completion events requires
polling the hardware. Proper software will give up the CPU
while waiting and only sample the event, not continually spin.

You can get away with software murder if you only need to program
something that saves some state between shutdowns. However, if
you have a writable flash file-system you need to do it right.

> 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

The timeout of (0) was really to make the code more obvious, the
facts being that we really need to get the CPU back as soon as
there are no higher-priority tasks computable. If yield() would
work like schedule(0), of course I'd use it. The major problem
with yield() probably has to do with accounting. The machine
"feels" as though the CPU is properly available when you need
it, however it appears to be spinning, using 100% system time.
This makes customers nervous.

> 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...
>
> I guess we could change schedule_timeout() to WARN_ON if 0 is being
> passed to it.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by John Ashcroft.
                 98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/