From: NeilBrown <neilb@suse.de>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: majianpeng <majianpeng@gmail.com>,
linux-raid <linux-raid@vger.kernel.org>
Subject: Re: [PATCH] md/raid1:using else-if instead if.
Date: Mon, 2 Apr 2012 11:58:36 +1000 [thread overview]
Message-ID: <20120402115836.76e98982@notabene.brown> (raw)
In-Reply-To: <4F78ECBF.3060700@zytor.com>
[-- Attachment #1: Type: text/plain, Size: 2447 bytes --]
On Sun, 01 Apr 2012 17:03:11 -0700 "H. Peter Anvin" <hpa@zytor.com> wrote:
> On 03/31/2012 07:29 PM, majianpeng wrote:
> > From 798f3fce3d077db049a44d0d2434261c937796e9 Mon Sep 17 00:00:00 2001
> > From: majianpeng <majianpeng@gmail.com>
> > Date: Sun, 1 Apr 2012 10:23:56 +0800
> > Subject: [PATCH] md/raid1:using else-if instead if.
> >
> > Signed-off-by: majianpeng <majianpeng@gmail.com>
> > ---
> > drivers/md/raid1.c | 3 +--
> > 1 files changed, 1 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> > index 4a40a20..a9de970 100644
> > --- a/drivers/md/raid1.c
> > +++ b/drivers/md/raid1.c
> > @@ -2024,8 +2024,7 @@ static void handle_sync_write_finished(struct r1conf *conf, struct r1bio *r1_bio
> > if (test_bit(BIO_UPTODATE, &bio->bi_flags) &&
> > test_bit(R1BIO_MadeGood, &r1_bio->state)) {
> > rdev_clear_badblocks(rdev, r1_bio->sector, s);
> > - }
> > - if (!test_bit(BIO_UPTODATE, &bio->bi_flags) &&
> > + } else if (!test_bit(BIO_UPTODATE, &bio->bi_flags) &&
> > test_bit(R1BIO_WriteError, &r1_bio->state)) {
> > if (!rdev_set_badblocks(rdev, r1_bio->sector, s, 0))
> > md_error(conf->mddev, rdev);
I don't like this option as it confuses the logic..
>
> It would be even better to:
>
> if (test_bit(BIO_UPDATE, &bio->bi_flags)) {
> if (test_bit(R1BIO_MadeGood, &r1_bio->state))
> rdev_clear_badblocks(rdev, r1_bio->sector, s);
> } else {
> if (test_bit(R1BIO_WriteError, &r1_bio->state)) {
> ...
>
and I don't really like adding unnecessary indentation.
>
> ... rather than testing the bit twice.
I'm really surprised that the compiler doesn't optimise that out.
I see:
0x0000000000004fb1 <+113>: mov 0x18(%rcx),%rax
0x0000000000004fb5 <+117>: test $0x1,%al
0x0000000000004fb7 <+119>: je 0x4f70 <handle_sync_write_finished+48>
which is the first test_bit(BIO_UPTODATE), then
0x0000000000004f70 <+48>: mov 0x18(%rcx),%rax
0x0000000000004f74 <+52>: test $0x1,%al
0x0000000000004f76 <+54>: jne 0x4f82 <handle_sync_write_finished+66>
so it is repeating a test that it already knows the answer too.
Why not just "je 0x4f78 <handle_sync_write_finished+56> I wonder.
Still, I'm much more interested in readability than this sort of micro
optimisation, so I'll leave the code as it is.
Thanks,
NeilBrown
>
> -hpa
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2012-04-02 1:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-01 2:29 [PATCH] md/raid1:using else-if instead if majianpeng
2012-04-02 0:03 ` H. Peter Anvin
2012-04-02 1:58 ` NeilBrown [this message]
2012-04-02 2:11 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120402115836.76e98982@notabene.brown \
--to=neilb@suse.de \
--cc=hpa@zytor.com \
--cc=linux-raid@vger.kernel.org \
--cc=majianpeng@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).