Re: [PATCH] cfq-prio #2

From: Nick Piggin
Date: Mon Nov 10 2003 - 09:44:00 EST




Jens Axboe wrote:

On Tue, Nov 11 2003, Nick Piggin wrote:


You acked the change actually :P
I guess it was done in mainline when AS was merged.


Probably missed the semantic change of may_queue.


Anyway I won't bother digging up the email, its been done now.


Maybe my version should be called elv_force_queue?


I just hate to see more of these, really. The original idea for
may_queue was just that, may this process queue io or not. We can make
it return something else, though, to indicate whether the process must
be able to queue. Is it really needed?


Its quite important. If the queue is full, and AS is waiting for a process
to submit a request, its got a long wait.

Maybe a lower limit for per process nr_requests. Ie. you may queue if this
queue has less than 128 requests _or_ you have less than 8 requests
outstanding. This would solve my problem. It would also give you a much more
appropriate scaling for server workloads, I think. Still, thats quite a
change in behaviour (simple to code though).


That basically belongs inside your may_queue for the io scheduler, imo.


You can force it to disallow the request, but you can't force it to allow
one (depending on a successful memory allocation, of course).


-
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/