On Thu, Jan 10, 2002 at 01:15:01PM -0800, Badari Pulavarty wrote:
> The issue with my (mostly) PAGE_SIZE RAW IO patch is, it could generate
> buffer heads with different b_size in a single IO request. Jens & Ben
> have concerns about some of the low level drivers not able to handle
> these. (it would be hard to analyse all the drivers to verify this).
>
> So, Andrea suggested we add a flag in "blk_dev" structure. Only the
> drivers which support variable size buffer heads in a single IO will
> set it. My RAW VARY patch will use this flag to see if I can do
> RAW VARY or not. Makes sense ?
The way I handled it in my O_DIRECT code for the same task (do
the largest I/O you can, instead of a hardcoded 512 or sw_blocksize) was
to merely choose the minimum alignment. See the patch in
<20020109195606.A16884@parcelfarce.linux.theplanet.co.uk>. In your
approach, you want leading blocks to be aligned at 512 or so, then all
4k aligned I/Os to be 4k size, then the trailing I/Os are aligned again
at their size. My approach was 'if aligned at 512, do all 512'. It is
slower than your approach for large I/Os aligned on 512, but it also
has the property of submitting identical blocksizes in one request.
Andrea has suggested that I work with you to be incremental on
top of your code. This would include managing a flag bit to decide if a
device can handle variable I/O sizes in one request. The issue I have
with that is that in the O_DIRECT case, the fallback is failure, not
slow I/O. IOW, in rawio, if the flag is false, you issue all I/Os with
a 512 blocksize. That's slow. However, in O_DIRECT, if the flag is
false, the sw_blocksize is 4096, and the alignment is 512, you fail with
EINVAL. That is bad. In my current patch, the O_DIRECT I/O would
succeed at a 512 byte blocksize. However, my patch doesn't touch rawio
at all.
Please have a look at my patch and maybe we can work on merging
our efforts.
Joel
--"The first thing we do, let's kill all the lawyers." -Henry VI, IV:ii
http://www.jlbec.org/ jlbec@evilplan.org - 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/
This archive was generated by hypermail 2b29 : Tue Jan 15 2002 - 21:00:49 EST