Re: RFC on io-stalls patch

[Andrea Arcangeli <andrea@suse.de>]

On Mon, Jul 14, 2003 at 09:51:39PM +0200, Jens Axboe wrote:
> -	rl = &q->rq;
> -	if (!list_empty(&rl->free) && !blk_oversized_queue(q)) {
> +	if ((rw == WRITE) && (blk_oversized_queue(q) || (rl->count < 4)))

did you disable the oversized queue check completely for reads? This
looks unsafe, you can end with loads of ram locked up this way, the
request queue cannot be limited in requests anymore. this isn't the
"request reservation", this a "nearly unlimited amount of ram locked in
for reads".

Of course, the more reads can be in the queue, the less the background
write loads will hurt parallel apps like a kernel compile as shown in
xtar_load.

This is very different from the schedule advantage provided by the old
queue model. If you allow an unlimited I/O queue for reads, that means
the I/O queues will be filled by an huge amount of reads and a few
writes (no matter how fast the xtar_load is writing to disk).

In the past (2.4.22pre4) the I/O queue would been at most 50/50, with
your patch it can be 90/10, hence it can generate an huge performance
difference, that can penealize tremendously the writers in server loads
using fsync plus it can hurt the VM badly if all ram is locked up by
parallel reads. Of course contest mostly cares about reads, not writes.

Overall I think your patch is unsafe and shouldn't be applied.

Still if you want to allow 50/50, go ahead, that logic in pre4 was an
order of magnitude more fair and generic than this patch.

Andrea