On Mon, 28 Aug 2000, Ingo Molnar wrote:
>no, it's not a good idea for the reason i described: 1) extensibility of
>the code itself (you can easily change a waitqueue-based code to
>multiple-threads, you cannot do it with the wake_up_process() variant) 2)
I agree, that most of the time using a waitqueue is preferred solution.
However I don't see as a riskious/broken hack allowing some aware piece of
code to use wake_up_process if it doesn't need the waitqueue and in some
case we don't need a waitqueue also in the long run.
>wake_up_process() is a scheduler-internal function and optimizations that
>go into waitqueues will not necesserily show up in wake_up_process(). As
I'd be curious to know which optimization will happen into the waitqueue
if only one task is sleeping into the waitqueue.
The optimization I can see are to choose _which_ task to wakeup when there
is more than one task registered into the waitqueue (as we're just doing
not efficiently in the case of wakeup from irq), but when the task
sleeping is only one I don't see what is worth to optimize that shouldn't
instead fit inside the wake_up_process path.
IMHO in the waitqueue layer there should be only the decision of _which_
task to wakeup, everything else doesn't belong there.
BTW, would you suggest to use a waitqueue also in
sched.c:process_timeout() too then? Looks like a plain slowdown and a
thing similar process_timeout() could be implemented also in a kernel
module for whatever reason and I think the usage of wake_up_process there
is pretty much obviously correct.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:21 EST