Consider the following request, with attached bh list:
req -> bh1 -> bh2 -> bh3 -> bh4
Lets say this is a 4kB fs, so each bh linked to the request is 4kB in
size. You'll then have
current_nr_sectors 8 (4096 >> 9)
nr_sectors 32 (the four buffer heads)
req->buffer == req->bh1->b_data
ps2esdi only processes one chunk of the time (looks at
current_nr_sectors for request and buffer size). Once you complete that
hunk and call end_request, your request will then look like this:
req -> bh2 -> bh3 -> bh4
current_nr_sectors 8
nr_sectors 24
req->buffer == req->bh2->b_data
and so it continues. This is the easy way to process requests. However,
if you can start I/O on more than one buffer at the time (scatter
gather), you could then setup your sg tables by browsing the entire
request buffer_head list and initiate I/O as needed.
Bigger requests on the queue, means more I/O in progress being possible.
There's no rule that you have to finish a request in one go, so even if
you can only handle eg 64 sectors per request with sg, you could do
just start I/O on as many segments as you can and simply don't dequeue
the request until it's completely done. So the max_sectors patch is
never really needed if you know what you are doing.
-- Jens Axboe- 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/