William Lee Irwin III wrote:
> @@ -153,15 +119,13 @@
> void __wait_on_buffer(struct buffer_head * bh)
> {
> wait_queue_head_t *wqh = bh_waitq_head(bh);
> - DEFINE_BH_WAIT(wait, bh);
> + DEFINE_WAIT_BIT(wait, &bh->b_state, BH_Lock);
>
> - do {
> - prepare_to_wait(wqh, &wait.wait, TASK_UNINTERRUPTIBLE);
> - if (buffer_locked(bh)) {
> - sync_buffer(bh);
> - io_schedule();
> - }
> - } while (buffer_locked(bh));
> + prepare_to_wait(wqh, &wait.wait, TASK_UNINTERRUPTIBLE);
> + if (buffer_locked(bh)) {
> + sync_buffer(bh);
> + io_schedule();
> + }
> finish_wait(wqh, &wait.wait);
> }
Why don't you need a do..while loop any more ?
There is also no loop in __wait_on_bit() in the completed patch series.
Cheers
Martin
William Lee Irwin III wrote:
>>+ prepare_to_wait(wqh, &wait.wait, TASK_UNINTERRUPTIBLE);
>>+ if (buffer_locked(bh)) {
>>+ sync_buffer(bh);
>>+ io_schedule();
>>+ }
>> finish_wait(wqh, &wait.wait);
>> }
On Fri, Sep 03, 2004 at 11:53:55AM +0200, Martin Wilck wrote:
> Why don't you need a do..while loop any more ?
> There is also no loop in __wait_on_bit() in the completed patch series.
Part of the point of filtered waitqueues is to reestablish wake-one
semantics. This means two things:
(a) those waiting merely for a bit to clear with no need to set it,
i.e. all they want is to know a transition from set to
clear occurred, are only woken once and don't need to loop
waking and sleeping
(b) Of those tasks waiting for a bit to clear so they can set it
exclusively, only one needs to be woken, and after the first
is woken, it promises to clear the bit again, so there is no
need to wake more tasks.
These two aspects of wake-one semantics give it highly attractive
performance characteristics.
-- wli
On Fri, Sep 03, 2004 at 11:53:55AM +0200, Martin Wilck wrote:
>> Why don't you need a do..while loop any more ?
>> There is also no loop in __wait_on_bit() in the completed patch series.
On Fri, Sep 03, 2004 at 02:42:47AM -0700, William Lee Irwin III wrote:
> Part of the point of filtered waitqueues is to reestablish wake-one
> semantics. This means two things:
> (a) those waiting merely for a bit to clear with no need to set it,
> i.e. all they want is to know a transition from set to
> clear occurred, are only woken once and don't need to loop
> waking and sleeping
> (b) Of those tasks waiting for a bit to clear so they can set it
> exclusively, only one needs to be woken, and after the first
> is woken, it promises to clear the bit again, so there is no
> need to wake more tasks.
Also, (a) still works in the presence of signals with interruptible
waits (which the VM and VFS do not now use); the sleeping function is
required to return -EINTR or some other nonzero value to indicate
abnormal termination, which in turn must be checked by the caller.
-- wli