Messages in this thread | | | Date | Tue, 14 Dec 2004 18:15:03 +0100 | From | Andrea Arcangeli <> | Subject | Re: dynamic-hz |
| |
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).
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...
I guess we could change schedule_timeout() to WARN_ON if 0 is being passed to it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |