Re: [GIT PULL] Queue free fix (was Re: [PATCH] block: Free queueresources at blk_release_queue())

[Christoph Hellwig]

On Wed, Nov 30, 2011 at 11:18:42AM +0100, Jens Axboe wrote:
> I agree on a+b, but c is definitely more than debatable. I have yet to
> see a device saturate its bandwidth on 4KB IOS. So merging on the write
> side is always going to be a win.

We shouldn't submit 4k I/O in the first place unless they truely are
random.  If you look at XFS for example you'd basically never see them.
The only small I/O in a typical workloads are individual btree blocks
and AG header updates, which generally can't be merged anyway.  Data I/O
happens in larger chunks generally, as do reads/writes of inodes
(generally in 32k chunks, with plans to go larger).

Note that the merges in the way the are done currently are one of the
most painful bits of the current request_fn based drivers.  They require
the addition of the struct request data structure, which needs to be
allocated and initialized for every bio, no matter if it's beeing merged
or not, and are the prime reason why make_request_fn and request_fn
style drivers can't operate on the same data structures.

I've been wondering if it would be possible to simply chain bios for
merging, and while it's theoretically possible I'm wondering about
the impact on drivers.  Fortunately scsi drivers generally don't touch
struct request directly, so it might be doable.
--
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/