xfs
[Top] [All Lists]

Re: [PATCH 04/23] block: Abstract out bvec iterator

To: Kent Overstreet <kmo@xxxxxxxxxxxxx>
Subject: Re: [PATCH 04/23] block: Abstract out bvec iterator
From: NeilBrown <neilb@xxxxxxx>
Date: Thu, 31 Oct 2013 14:29:36 +1100
Cc: axboe@xxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, hch@xxxxxxxxxxxxx, tj@xxxxxxxxxx, nab@xxxxxxxxxxxxxxx, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>, Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>, Paul Mackerras <paulus@xxxxxxxxx>, "Ed L. Cashin" <ecashin@xxxxxxxxxx>, Nick Piggin <npiggin@xxxxxxxxx>, Lars Ellenberg <drbd-dev@xxxxxxxxxxxxxxxx>, Jiri Kosina <jkosina@xxxxxxx>, Matthew Wilcox <willy@xxxxxxxxxxxxxxx>, Geoff Levand <geoff@xxxxxxxxxxxxx>, Yehuda Sadeh <yehuda@xxxxxxxxxxx>, Sage Weil <sage@xxxxxxxxxxx>, Alex Elder <elder@xxxxxxxxxxx>, ceph-devel@xxxxxxxxxxxxxxx, Joshua Morris <josh.h.morris@xxxxxxxxxx>, Philip Kelleher <pjk1939@xxxxxxxxxxxxxxxxxx>, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, "Michael S. Tsirkin" <mst@xxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Alasdair Kergon <agk@xxxxxxxxxx>, Mike Snitzer <snitzer@xxxxxxxxxx>, dm-devel@xxxxxxxxxx, Martin Schwidefsky <schwidefsky@xxxxxxxxxx>, Heiko Carstens <heiko.carstens@xxxxxxxxxx>, linux390@xxxxxxxxxx, Boaz Harrosh <bharrosh@xxxxxxxxxxx>, Benny Halevy <bhalevy@xxxxxxxxxx>, "James E.J. Bottomley" <JBottomley@xxxxxxxxxxxxx>, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>, Alexander Viro <viro@xxxxxxxxxxxxxxxxxx>, Chris Mason <chris.mason@xxxxxxxxxxxx>, "Theodore Ts'o" <tytso@xxxxxxx>, Andreas Dilger <adilger.kernel@xxxxxxxxx>, Jaegeuk Kim <jaegeuk.kim@xxxxxxxxxxx>, Steven Whitehouse <swhiteho@xxxxxxxxxx>, Dave Kleikamp <shaggy@xxxxxxxxxx>, Joern Engel <joern@xxxxxxxxx>, Prasad Joshi <prasadjoshi.linux@xxxxxxxxx>, Trond Myklebust <Trond.Myklebust@xxxxxxxxxx>, KONISHI Ryusuke <konishi.ryusuke@xxxxxxxxxxxxx>, Mark Fasheh <mfasheh@xxxxxxxx>, Joel Becker <jlbec@xxxxxxxxxxxx>, Ben Myers <bpm@xxxxxxx>, xfs@xxxxxxxxxxx, Steven Rostedt <rostedt@xxxxxxxxxxx>, Frederic Weisbecker <fweisbec@xxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Len Brown <len.brown@xxxxxxxxx>, Pavel Machek <pavel@xxxxxx>, "Rafael J. Wysocki" <rjw@xxxxxxx>, Herton Ronaldo Krzesinski <herton.krzesinski@xxxxxxxxxxxxx>, Ben Hutchings <ben@xxxxxxxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Guo Chao <yan@xxxxxxxxxxxxxxxxxx>, Asai Thambi S P <asamymuthupa@xxxxxxxxxx>, Selvan Mani <smani@xxxxxxxxxx>, Sam Bradshaw <sbradshaw@xxxxxxxxxx>, Wei Yongjun <yongjun_wei@xxxxxxxxxxxxxxxxx>, Roger Pau Monnà <roger.pau@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>, Sebastian Ott <sebott@xxxxxxxxxxxxxxxxxx>, Christian Borntraeger <borntraeger@xxxxxxxxxx>, Minchan Kim <minchan@xxxxxxxxxx>, Jiang Liu <jiang.liu@xxxxxxxxxx>, Nitin Gupta <ngupta@xxxxxxxxxx>, Jerome Marchand <jmarchand@xxxxxxxxxx>, Joe Perches <joe@xxxxxxxxxxx>, Peng Tao <tao.peng@xxxxxxx>, Andy Adamson <andros@xxxxxxxxxx>, fanchaoting <fanchaoting@xxxxxxxxxxxxxx>, Jie Liu <jeff.liu@xxxxxxxxxx>, Sunil Mushran <sunil.mushran@xxxxxxxxx>, "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>, Namjae Jeon <namjae.jeon@xxxxxxxxxxx>, Pankaj Kumar <pankaj.km@xxxxxxxxxxx>, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, Mel Gorman <mgorman@xxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <1383077896-4132-5-git-send-email-kmo@xxxxxxxxxxxxx>
References: <1383077896-4132-1-git-send-email-kmo@xxxxxxxxxxxxx> <1383077896-4132-5-git-send-email-kmo@xxxxxxxxxxxxx>
On Tue, 29 Oct 2013 13:17:57 -0700 Kent Overstreet <kmo@xxxxxxxxxxxxx> wrote:

> Immutable biovecs are going to require an explicit iterator. To
> implement immutable bvecs, a later patch is going to add a bi_bvec_done
> member to this struct; for now, this patch effectively just renames
> things.
> 
> Signed-off-by: Kent Overstreet <kmo@xxxxxxxxxxxxx>


> diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt
> index 8df5e8e..2101e71 100644
> --- a/Documentation/block/biodoc.txt
> +++ b/Documentation/block/biodoc.txt
> @@ -447,14 +447,13 @@ struct bio_vec {
>   * main unit of I/O for the block layer and lower layers (ie drivers)
>   */
>  struct bio {
> -       sector_t            bi_sector;
>         struct bio          *bi_next;    /* request queue link */
>         struct block_device *bi_bdev; /* target device */
>         unsigned long       bi_flags;    /* status, command, etc */
>         unsigned long       bi_rw;       /* low bits: r/w, high: priority */
>  
>         unsigned int  bi_vcnt;     /* how may bio_vec's */
> -       unsigned int  bi_idx;         /* current index into bio_vec array */
> +       struct bvec_iter      bi_iter;        /* current index into bio_vec 
> array */
>  
>         unsigned int  bi_size;     /* total size in bytes */
>         unsigned short        bi_phys_segments; /* segments after physaddr 
> coalesce*/
> @@ -480,7 +479,7 @@ With this multipage bio design:
>  - Code that traverses the req list can find all the segments of a bio
>    by using rq_for_each_segment.  This handles the fact that a request
>    has multiple bios, each of which can have multiple segments.
> -- Drivers which can't process a large bio in one shot can use the bi_idx
> +- Drivers which can't process a large bio in one shot can use the bi_iter
>    field to keep track of the next bio_vec entry to process.
>    (e.g a 1MB bio_vec needs to be handled in max 128kB chunks for IDE)
>    [TBD: Should preferably also have a bi_voffset and bi_vlen to avoid 
> modifying
> @@ -589,7 +588,7 @@ driver should not modify these values. The block layer 
> sets up the
>  nr_sectors and current_nr_sectors fields (based on the corresponding
>  hard_xxx values and the number of bytes transferred) and updates it on
>  every transfer that invokes end_that_request_first. It does the same for the
> -buffer, bio, bio->bi_idx fields too.
> +buffer, bio, bio->bi_iter fields too.
>  
>  The buffer field is just a virtual address mapping of the current segment
>  of the i/o buffer in cases where the buffer resides in low-memory. For high

Would it make sense to add some details of "bvec_iter" to this document?

Or will that come later?

NeilBrown

Attachment: signature.asc
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>