lkml.org 
[lkml]   [2001]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] generic IO write clustering

    On Sat, 20 Jan 2001, Christoph Hellwig wrote:

    <snip>

    > I think there is a big disadvantage of this appropeach:
    > To find out which pages are clusterable, we need do do bmap/get_block,
    > that means we have to go through the block-allocation functions, which
    > is rather expensive, and then we have to do it again in writepage, for
    > the pages that are actually clustered bt the VM.

    In case the metadata was not already cached before ->cluster() (in this
    case there is no disk IO at all), ->cluster() will cache it avoiding
    further disk accesses by writepage (or writepages()).

    > Another thing I dislike is that the flushing gets more complicated with
    > yout VM-level clustering. Now (and with my appropeach I'll describe
    > below) flushing is write it out now and do whatever you else want,
    > with you design it is 'find out pages beside this page in write out
    > a bunch of them' - much more complicated. I'd like it abstracted out.

    I dont see your point here. What I'm missing?

    > > The idea is to work with delayed allocated pages, too. A filesystem which
    > > has this feature can, at its "cluster" operation, allocate delayed pages
    > > contiguously on disk, and then return to the VM code which now can
    > > potentially write a bunch of dirty pages in a few big IO operations.
    >
    > That does also work nicely together with ->writepage level IO clustering.
    >
    > > I'm sure that a bit of tuning to know the optimal cluster size will be
    > > needed. Also some fs locking problems will appear.
    >
    > Sure, but again that's an issue for every kind of IO clustering...
    >
    >
    > No my proposal. I prefer doing it in writepage, as stated above.
    > Writepage loops over the MAX_CLUSTERED_PAGES/2 dirty pages before and
    > behind the initial page, it first uses test wether the page should be
    > clustered (a callback from vm, highly 'balanceable'...), then does
    > a bmap/get_block to check wether it is contingous.
    >
    > Finally the IO is submitted using a submit_bh loop, or when using a
    > kiobuf-based IO path all clustered pages are passed down to ll_rw_kio
    > in one piece.
    > As you see the easy integration with the new bulk-IO mechanisms is also
    > an advantage of this proposal, without the need a new multi-page a_op.

    IMHO replicating the code is the worst thing.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:02    [W:0.022 / U:33.924 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site