Re: memory barrier in ll_rw_blk.c (was Re: [PATCH][5/?] count writeback pages in nr_scanned)

[Jens Axboe <axboe@suse.de>]

On Thu, Jan 06 2005, Nick Piggin wrote:
> Jens Axboe wrote:
> >On Thu, Jan 06 2005, Nick Piggin wrote:
> >
> 
> >>No that's right... but between the prepare_to_wait and the io_schedule,
> >>get_request takes the lock and checks nr_requests. I think we are safe?
> >
> >
> >It looks like it, yes you are right. But it looks to be needed a few
> >lines further down instead, though :-)
> >
> >===== drivers/block/ll_rw_blk.c 1.281 vs edited =====
> >--- 1.281/drivers/block/ll_rw_blk.c     2004-12-01 09:13:57 +01:00
> >+++ edited/drivers/block/ll_rw_blk.c    2005-01-06 09:32:19 +01:00
> >@@ -1630,11 +1630,11 @@
> >        if (rl->count[rw] < queue_congestion_off_threshold(q))
> >                clear_queue_congested(q, rw);
> >        if (rl->count[rw]+1 <= q->nr_requests) {
> >-               smp_mb();
> >                if (waitqueue_active(&rl->wait[rw]))
> >                        wake_up(&rl->wait[rw]);
> >                blk_clear_queue_full(q, rw);
> >        }
> >+       smp_mb();
> >        if (unlikely(waitqueue_active(&rl->drain)) &&
> >            !rl->count[READ] && !rl->count[WRITE])
> >                wake_up(&rl->drain);
> >
> 
> Yes, looks like you're right there.
> 
> Any point in doing it like this
> 
> 	if (!rl->count[READ] && !rl->count[WRITE]) {
> 		smb_mb();
> 		if (unlikely(waitqueue_active(...)))
> 			wake_up()
> 	}
> 
> I wonder? I don't have any feeling of how memory barriers impact performance
> on a very parallel system with CPUs that do lots of memory reordering like
> POWER5.

I had the same idea - I think it's a good idea, it's definitely an
optimization worth doing.

-- 
Jens Axboe