On Thu, 24 Aug 2000, Michael Rothwell wrote:

>bdflush on 2.4 still uses wake_up_process, but Ingo said that kernel
>threads should use waitqueues instead. We have a thread similar in

At the moment (test7) there would be no difference for them to use
waitqueue except the waitqueue would be slower.

>functionality to bdflush, but more suited to our needs, called jflush.
>We use wake_up_process. Since the only documentation available for Linux
>is typically the source, we thought this was the way to go. According to
>Ingo, it's not. He has not eleborated.
>
>Can some tell me the pros and cons of wake_up_process vs. waitqueues?

If more than one task is going to sleep on the waitqueue then we can do
optimization on the selection of the task to wakeup instead of doing pure
FIFO (there's one optimization at the moment in the wakeup from irqs that
btw, incorrectly also isn't breaking the loop as soon as possible and that
has as side effect to changes the FIFO sometime to a kind of
SMP-affine-LIFO instead of doing a SMP-affine-FIFO).

In the bdflush case only bdflush would be sleeping in the waitqueue, thus
using wake_up_process is faster and it's fine to use it.

>Also, will bdflush ("the documentation") be updated?

The ""documentation"" is in sync with the code at the moment.

IIRC Ingo said his tree have further optimizations, but when there's only
one task sleeping on the waitqueue I don't see which optimization can he
do outside wake_up_process, so I think the current "documentation" won't
change even he will choose to merge his optimization with Linus.

Actually (test7) it's always good idea to use "wake_up_process()" instead
of a waitqueue, if in the waitqueue there would be only 1 task at once.

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/