Messages in this thread | | | Date | Tue, 09 Mar 2004 10:50:02 +1100 | From | Nick Piggin <> | Subject | Re: blk_congestion_wait racy? |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |