lkml.org 
[lkml]   [2004]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: [PATCH 15/22] filemap_fdatawrite range interface
    On Fri, Jul 02, 2004 at 06:30:30PM +0530, Suparna Bhattacharya wrote:
    > The patchset contains modifications and fixes to the AIO core
    > to support the full retry model, an implementation of AIO
    > support for buffered filesystem AIO reads and O_SYNC writes
    > (the latter courtesy O_SYNC speedup changes from Andrew Morton),
    > an implementation of AIO reads and writes to pipes (from
    > Chris Mason) and AIO poll (again from Chris Mason).
    >
    > Full retry infrastructure and fixes
    > [1] aio-retry.patch
    > [2] 4g4g-aio-hang-fix.patch
    > [3] aio-retry-elevated-refcount.patch
    > [4] aio-splice-runlist.patch
    >
    > FS AIO read
    > [5] aio-wait-page.patch
    > [6] aio-fs_read.patch
    > [7] aio-upfront-readahead.patch
    >
    > AIO for pipes
    > [8] aio-cancel-fix.patch
    > [9] aio-read-immediate.patch
    > [10] aio-pipe.patch
    > [11] aio-context-switch.patch
    >
    > Concurrent O_SYNC write speedups using radix-tree walks
    > [12] writepages-range.patch
    > [13] fix-writeback-range.patch
    > [14] fix-writepages-range.patch
    > [15] fdatawrite-range.patch

    --
    Suparna Bhattacharya (suparna@in.ibm.com)
    Linux Technology Center
    IBM Software Lab, India

    ----------------------------------------------------------

    From: Suparna Bhattacharya

    Range based equivalent of filemap_fdatawrite for O_SYNC writers (to go
    with writepages range support added to mpage_writepages).
    If both <start> and <end> are zero, then it defaults to writing
    back all of the mapping's dirty pages.


    filemap.c | 23 +++++++++++++++++++++--
    1 files changed, 21 insertions(+), 2 deletions(-)

    --- aio/mm/filemap.c 2004-06-18 13:58:26.682069240 -0700
    +++ fdatawrite-range/mm/filemap.c 2004-06-18 14:07:25.456163128 -0700
    @@ -134,20 +134,26 @@ static inline int sync_page(struct page
    }

    /**
    - * filemap_fdatawrite - start writeback against all of a mapping's dirty pages
    + * filemap_fdatawrite_range - start writeback against all of a mapping's
    + * dirty pages that lie within the byte offsets <start, end>
    * @mapping: address space structure to write
    + * @start: offset in bytes where the range starts
    + * @end : offset in bytes where the range ends
    *
    * If sync_mode is WB_SYNC_ALL then this is a "data integrity" operation, as
    * opposed to a regular memory * cleansing writeback. The difference between
    * these two operations is that if a dirty page/buffer is encountered, it must
    * be waited upon, and not just skipped over.
    */
    -static int __filemap_fdatawrite(struct address_space *mapping, int sync_mode)
    +static int __filemap_fdatawrite_range(struct address_space *mapping,
    + loff_t start, loff_t end, int sync_mode)
    {
    int ret;
    struct writeback_control wbc = {
    .sync_mode = sync_mode,
    .nr_to_write = mapping->nrpages * 2,
    + .start = start,
    + .end = end,
    };

    if (mapping->backing_dev_info->memory_backed)
    @@ -157,12 +163,25 @@ static int __filemap_fdatawrite(struct a
    return ret;
    }

    +static inline int __filemap_fdatawrite(struct address_space *mapping,
    + int sync_mode)
    +{
    + return __filemap_fdatawrite_range(mapping, 0, 0, sync_mode);
    +}
    +
    int filemap_fdatawrite(struct address_space *mapping)
    {
    return __filemap_fdatawrite(mapping, WB_SYNC_ALL);
    }
    EXPORT_SYMBOL(filemap_fdatawrite);

    +int filemap_fdatawrite_range(struct address_space *mapping,
    + loff_t start, loff_t end)
    +{
    + return __filemap_fdatawrite_range(mapping, start, end, WB_SYNC_ALL);
    +}
    +EXPORT_SYMBOL(filemap_fdatawrite_range);
    +
    /*
    * This is a mostly non-blocking flush. Not suitable for data-integrity
    * purposes - I/O may not be started against all dirty pages.
    -
    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/
    \
     
     \ /
      Last update: 2005-03-22 14:04    [W:0.040 / U:87.972 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site