What if each read from the application was broken into 3 segments :
<initial> <page-aligned> <final>
where <initial> and <final> were handled through 1K (or even 512 byte)
requests and the page-aligned part through
4K requests ? That would take care of the device boundary problem and allow
the efficiency of larger requests for the most
Could you briefly explain how you planned to coalesce the 512 byte kiovec
requests ? Would it be redundant for accesses to
SCSI devices (where some merging is done by the SCSI layers too) ?
Enterprise Linux Group, IBM TJ Watson Research Center
(914) 945 2851, T/L 862 2851
Andrea Arcangeli <andrea@... on 10/06/2001
Sent by: lse-tech-admin@...
To: Bill Hartner <hartner@...>
cc: Shailabh Nagar/Watson/IBM@..., lse-tech@...
Subject: Re: [Lse-tech] Patch & module to test raw I/O "sector" sizes
On Fri, Oct 05, 2001 at 12:22:20PM -0500, Bill Hartner wrote:
> Do you know of any reason why the size could not be changed to 4096
> for both raw and direct i/o ? Would this break some block device drivers
I had to keep it fixed to 1k because the blkdev size API also uses a
granularity of 1k and so doing I/O with a granularity over 1k would end
sending I/O requests to blkdev beyond the end of the device, this
resulted into problems with partitions sizes not multiple of 4k.
Of course at first I used 4k default granularity for both rawio and
BTW, with 2.4.11 things changed again, now the granularity of the blkdev
I/O depends on the fs since there's not aliasing any longer between
buffercache and blkdev layer.
Anyways the plan was to rewrite the kiovec I/O routine so that using
512byte granularity it still runs as fast as 4k. I once started writing
the b_size coalescing, for some reason it was crashing because I did
probably too many changes, so I gave up and avoided that bits, since I
was using 4k by default anyways at that time, but it's certaily doable
again. The performance results after the b_size coalescing is unknown
at the moment though.
Lse-tech mailing list