From: Lars Ellenberg <lars.ellenberg@linbit.com>
To: drbd-dev@lists.linbit.com
Subject: Re: [Drbd-dev] Problems with DRBD merge-bvec function
Date: Mon, 14 Apr 2008 10:55:19 +0200 [thread overview]
Message-ID: <20080414085519.GA32260@soda.linbit> (raw)
In-Reply-To: <342BAC0A5467384983B586A6B0B3767108F030CD@EXNA.corp.stratus.com>
On Sun, Apr 13, 2008 at 05:38:10PM -0400, Graham, Simon wrote:
> > > That's what I'm testing at the moment -- I reverted the checks in
> > both
> > > drbd_merge_bvec and drbd_make_request_26.
> >
> > let us know what the impact on performance is.
> >
>
> It makes things a little better but not much -- after staring at this
> for a while, I realized that I've been looking at the disk stats for the
> LVM device underneath DRBD (because DRBD currently doesn't implement the
> counters exposed in /proc/diskstats) -- at this level, the average size
> of a transfer is reduced because of the meta data updates that are going
> on; with the specific workload I am testing, I see about 50 AL cache
> misses per second - obviously not good (and yes I am experimenting with
> increasing the size, but this test is vicious and does random writes all
> over the disk).
>
> I've actually been working on adding support for the standard disk
> counters - will probably submit a patch for that shortly on the
> assumption that it's generally interesting.
great.
> > but maybe this had not been your problem at all?
> > if any of the lower level devices has a merge_bvec function itself,
> > drbd falls back to "PAGE_SIZE" max-segments, unless you have
> "use-bmbv"
> > enabled, because we currently cannot cope with bios that need not be
> > split on the Primary, but would suddenly be split on the Secondary due
> > to different lower level constraints.
>
> They don't. However, I don't think the code actually behaves the way you
> describe, unless I'm missing something -- in the merge-bvec routine (in
> 8.0) it has:
>
> limit = DRBD_MAX_SEGMENT_SIZE - ((bio_offset &
> (DRBD_MAX_SEGMENT_SIZE-1)) + bio_size);
>
> if (limit < 0) limit = 0;
> if (bio_size == 0) {
> if (limit <= bvec->bv_len) limit = bvec->bv_len;
> } else if (limit && inc_local(mdev)) {
> struct request_queue * const b =
> mdev->bc->backing_bdev->bd_disk->queue;
> if(b->merge_bvec_fn && mdev->bc->dc.use_bmbv) {
> backing_limit = b->merge_bvec_fn(b,bio,bvec);
> limit = min(limit,backing_limit);
> }
> dec_local(mdev);
> }
>
> To me, this says it will use the normal 32KB boundary unless use_bmbv is
> set in which case it uses the minimum of ours and the lower devices
> value... I don't see anything here that would limit the size to 4K.
right. only, that code will not be used.
if the lover level device has a bio merge bvec fn,
drbd announces a fixed maximum segment size of PAGE_SIZE, since that
is the common denominator and all block devices are required to handle
that. there just will not be any merge_bvec fn announced then.
--
: Lars Ellenberg Tel +43-1-8178292-55 :
: LINBIT Information Technologies GmbH Fax +43-1-8178292-82 :
: Vivenotgasse 48, A-1120 Vienna/Europe http://www.linbit.com :
next prev parent reply other threads:[~2008-04-14 8:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-10 18:39 [Drbd-dev] Problems with DRBD merge-bvec function Graham, Simon
2008-04-10 21:21 ` Lars Ellenberg
2008-04-10 22:13 ` Graham, Simon
2008-04-11 6:45 ` Lars Ellenberg
[not found] ` <342BAC0A5467384983B586A6B0B3767108F02F3F@EXNA.corp.s tratus.com>
2008-04-13 21:38 ` Graham, Simon
2008-04-14 8:55 ` Lars Ellenberg [this message]
2008-04-14 19:21 ` [Drbd-dev] Perf issues with DRBD when doing a lot of random I/O Graham, Simon
2008-04-14 21:59 ` Lars Ellenberg
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=20080414085519.GA32260@soda.linbit \
--to=lars.ellenberg@linbit.com \
--cc=drbd-dev@lists.linbit.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