[Top] [All Lists]

Re: Re: [PATCH 0/8] Set bi_rw when alloc bio before call bio_add_page.

To: "Dave Chinner" <david@xxxxxxxxxxxxx>, "Neil Brown" <neilb@xxxxxxx>
Subject: Re: Re: [PATCH 0/8] Set bi_rw when alloc bio before call bio_add_page.
From: majianpeng <majianpeng@xxxxxxxxx>
Date: Tue, 31 Jul 2012 08:55:59 +0800
Cc: axboe <axboe@xxxxxxxxx>, "konrad.wilk" <konrad.wilk@xxxxxxxxxx>, "chris.mason" <chris.mason@xxxxxxxxxxxx>, viro <viro@xxxxxxxxxxxxxxxxxx>, tytso <tytso@xxxxxxx>, "adilger.kernel" <adilger.kernel@xxxxxxxxx>, shaggy <shaggy@xxxxxxxxxx>, mfasheh <mfasheh@xxxxxxxx>, jlbec <jlbec@xxxxxxxxxxxx>, bpm <bpm@xxxxxxx>, elder <elder@xxxxxxxxxx>, jfs-discussion <jfs-discussion@xxxxxxxxxxxxxxxxxxxxx>, linux-kernel <linux-kernel@xxxxxxxxxxxxxxx>, xfs <xfs@xxxxxxxxxxx>, linux-btrfs <linux-btrfs@xxxxxxxxxxxxxxx>, linux-ext4 <linux-ext4@xxxxxxxxxxxxxxx>, linux-raid <linux-raid@xxxxxxxxxxxxxxx>, linux-fsdevel <linux-fsdevel@xxxxxxxxxxxxxxx>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:references:x-priority:x-has-attach:x-mailer :mime-version:message-id:content-type:content-transfer-encoding; bh=4mdrIrbHYwqgBn5/Eoc6jxpHzzIUbMfQmIMy8/sBzv4=; b=mupTxpusvWb0PLDuX0At0Vrx+GEwgS6EiCLLRd4+WbvK1Z3ieGY8Fy76tVQBzFi1Jj Q/sAkuvRAMilq7EaPUGCOUCIoFldW90vW+74Qc4qaC0t95FbPmgq4Lmw0A/tEUzYDiyH 4ze3JkZsgpMYO5G3lNB6wvBYM3gnv2DJou9HDpURG6r5SbdaDbpQ15R24/NFr3eI483V 1bLnMzE1mfev1gWtlyrD7jPmwCRQjpeYMJoDM5/975WlFB28OYb8wsV++YssGTZES0m5 DfvprSwXPly1oba5lDxOB9BBqHol7Yz0UDix/AeYRp6AkCueNCQ5+WwI2ffQkbjNd08G 9h9Q==
References: <201207301514247032532@xxxxxxxxx>, <20120730214213.GF2877@dastard>
On 2012-07-31 05:42 Dave Chinner <david@xxxxxxxxxxxxx> Wrote:
>On Mon, Jul 30, 2012 at 03:14:28PM +0800, majianpeng wrote:
>> When exec bio_alloc, the bi_rw is zero.But after calling bio_add_page,
>> it will use bi_rw.
>> Fox example, in functiion __bio_add_page,it will call merge_bvec_fn().
>> The merge_bvec_fn of raid456 will use the bi_rw to judge the merge.
>> >> if ((bvm->bi_rw & 1) == WRITE)
>> >> return biovec->bv_len; /* always allow writes to be mergeable */
>So if bio_add_page() requires bi_rw to be set, then shouldn't it be
>set up for every caller? I noticed there are about 50 call sites for
>bio_add_page(), and you've only touched about 10 of them. Indeed, I
>notice that the RAID0/1 code uses bio_add_page, and as that can be
>stacked on top of RAID456, it also needs to set bi_rw correctly.
>As a result, your patch set is nowhere near complete, not does it
>document that bio_add_page requires that bi_rw be set before calling
>(which is the new API requirement, AFAICT).
There are many place call bio_add_page and I send some of those. Because my 
abilty, so I only send 
some patchs which i understand clearly.
In __bio_add_page:
>>if (q->merge_bvec_fn) {
>>                              struct bvec_merge_data bvm = {
>>                                      /* prev_bvec is already charged in
>>                                         bi_size, discharge it in order to
>>                                         simulate merging updated prev_bvec
>>                                         as new bvec. */
>>                                      .bi_bdev = bio->bi_bdev,
>>                                      .bi_sector = bio->bi_sector,
>>                                      .bi_size = bio->bi_size - prev_bv_len,
>>                                      .bi_rw = bio->bi_rw,
>>                              };
it used bio->bi_rw.
Before raid5_mergeable_bvec appearing, in kernel 'merge_bvec_fn' did not use 
But i think we shold not suppose bi_rw not meanless.
And I think we not need an new API to do.
Most used bio_alloc and bio_add_page, like this:
>>      bio = bio_alloc(gfp_mask, 1);
>>              if (!bio) 
>>                      ret = -ENOMEM;
>>              bio->bi_sector = sector;
>>              bio->bi_end_io = bio_batch_end_io;
>>              bio->bi_bdev = bdev;
>>              bio->bi_private = &bb;
We only add bio->bi_rw = value;
But we shold modify Document for this.

>So, my question is whether the RAID456 code is doing something
>valid.  That write optimisation is clearly not enabled for a
>significant amount of code and filesystems, so the first thing to do
>is quantify the benefit of the optimisation. I can't evalute the
>merit of this change without data telling me it is worthwhile, and
>it's a lot of code to churn for no benefit....
Sorry, we do not think the 'merge_bvec_fn' did not use bi_rw.
>Dave Chinner
<Prev in Thread] Current Thread [Next in Thread>