Re: blk_congestion_wait racy?

[Nick Piggin]

Martin Schwidefsky wrote:

> > Gad, that'll make the VM scan its guts out.
> Yes, I expected something like this.
>
>
> > > 2.6.4-rc2 + "fix" with 1 cpu
> > > sys     0m0.880s
> > >
> > > 2.6.4-rc2 + "fix" with 2 cpu
> > > sys     0m1.560s
> > system time was doubled though.
> That would be the additional cost for not waiting.

I'd say its more like cacheline contention or something: reclaim
won't simply be spinning with nothing to do because you're dirtying
plenty of memory. And if any queues were full it will mostly just be
blocking in the block layer.

> > Nope, something is obviously broken.   I'll take a look.
> That would be very much appreciated.

I'm looking at 2.6.1 source, so apologies if I'm wrong, but
drivers/block/ll_rw_blk.c:
freed_request does not need the memory barrier because the queue is
protected by the per queue spinlock. And I think clear_queue_congested
should have a memory barrier right before if (waitqueue_active(wqh)).

Another problem is that if there are no requests anywhere in the system,
sleepers in blk_congestion_wait will not get kicked. blk_congestion_wait
could probably have blk_run_queues moved after prepare_to_wait, which
might help.

Just some ideas.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/