All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Hua Zhong <hzhong@gmail.com>
Cc: linux-kernel@vger.kernel.org, akpm@osdl.org,
	James.Bottomley@SteelEye.com
Subject: Re: [PATCH] likely cleanup: revert unlikely in ll_back_merge_fn
Date: Wed, 26 Apr 2006 07:20:50 +0200	[thread overview]
Message-ID: <20060426052049.GV4102@suse.de> (raw)
In-Reply-To: <004d01c668b0$a9c79540$853d010a@nuitysystems.com>

On Tue, Apr 25 2006, Hua Zhong wrote:
> It seems that new BIOs do not have BIO_SEG_VALID set. So when you do
> sequential IO, the IO being back-merged should always have not had
> valid segments.
> 
> I ran bonnie++ and it shows the same thing.

But blk_recount_segments() sets the BIO_SEG_VALID flag. Ugh ok
__bio_add_page() basically kills the flag. James, I think you are the
author of that addition, does it really need to be so restrictive?

        /* If we may be able to merge these biovecs, force a recount */
        if (bio->bi_vcnt && (BIOVEC_PHYS_MERGEABLE(bvec-1, bvec) ||
            BIOVEC_VIRT_MERGEABLE(bvec-1, bvec)))
                bio->bi_flags &= ~(1 << BIO_SEG_VALID);

with that in place, we may as well just remove ->bi_phys_segments
and ->bi_hw_segments since we'll be calculating the values over and over
again while building up a bio.

-- 
Jens Axboe


  reply	other threads:[~2006-04-26  5:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-25 18:18 [PATCH] likely cleanup: revert unlikely in ll_back_merge_fn Hua Zhong
2006-04-25 18:30 ` Jens Axboe
2006-04-25 21:38   ` Hua Zhong
2006-04-26  5:20     ` Jens Axboe [this message]
2006-04-26 13:50       ` James Bottomley
2006-04-26 13:55         ` Jens Axboe
2006-04-26 14:24           ` James Bottomley
2006-04-27 14:39             ` Jens Axboe
2006-04-26 17:06   ` Hua Zhong
2006-04-30 19:25   ` Pavel Machek

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=20060426052049.GV4102@suse.de \
    --to=axboe@suse.de \
    --cc=James.Bottomley@SteelEye.com \
    --cc=akpm@osdl.org \
    --cc=hzhong@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.