Re: [Lse-tech] Patch & module to test raw I/O "sector" sizes

[Shailabh N. <na...@us...>]

Andrea,

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
part.

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) ?

Thanks,
Shailabh Nagar
Enterprise Linux Group, IBM TJ Watson Research Center
(914) 945 2851, T/L 862 2851


Andrea Arcangeli <an...@su...>@lists.sourceforge.net on 10/06/2001
08:16:01 PM

Sent by:  lse...@li...


To:   Bill Hartner <ha...@au...>
cc:   Shailabh Nagar/Watson/IBM@IBMUS, lse...@li...
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
directio :).

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.

Andrea

_______________________________________________
Lse-tech mailing list
Lse...@li...
https://lists.sourceforge.net/lists/listinfo/lse-tech