On Thu, Jun 12, 2003 at 01:20:44PM +1000, Nick Piggin wrote:
> Its no less fair this way, tasks will still be woken in fifo
> order. They will just be given the chance to submit a batch
> of requests.
If you change the behaviour with queued_task_nr > batch_requests it is
less fair period. Whatever else thing I don't care about right now
because it is a minor cpu improvement anyways.
I'm not talking about performance, I'm talking about latency and
fariness only. This is the whole point of the ->full logic.
> I think the cpu utilization gain of waking a number of tasks
> at once would be outweighed by advantage of waking 1 task
> and not putting it to sleep again for a number of requests.
> You obviously are not claiming concurrency improvements, as
> your method would also increase contention on the io lock
> (or the queue lock in 2.5).
I'm claiming that with queued_task_nr > batch_requests the
batch_requests logic still has a chance to save some cpu, this is the
only reason I didn't nuke it completely as you suggested some email ago.
> Then you have the cache gains of running each task for a
> longer period of time. You also get possible IO scheduling
> Consider 8 requests, batch_requests at 4, 10 tasks writing
> to different areas of disk.
> Your method still only allows each task to have 1 request in
> the elevator at once. Mine allows each to have a run of 4
> requests in the elevator.
I definitely want 1 request in the elevator at once or we can as well
drop your ->full and return to be unfair. The whole point of ->full is
to get the total fariness, across the tasks in the queue queue, and for
tasks outside the queue calling get_request too. Since not all tasks
will fit in the I/O queue, providing a very fair FIFO in the
wait_for_request is fundamental to provide any sort of latency
guarantee IMHO (the fact an _exclusive wakeup removal that mixes stuff
and probably has the side effect of being more fair, made that much
difference to mainline users kind of confirms that).
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jun 15 2003 - 22:00:31 EST