From: Jens Axboe <jens.axboe@oracle.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Mike Anderson <andmike@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org,
Alasdair Graeme Kergon <agk@redhat.com>
Subject: Re: [PATCH] Optimize lock in queue unplugging
Date: Wed, 7 May 2008 09:45:57 +0200 [thread overview]
Message-ID: <20080507074556.GQ329@kernel.dk> (raw)
In-Reply-To: <Pine.LNX.4.64.0805042335440.5512@engineering.redhat.com>
On Mon, May 05 2008, Mikulas Patocka wrote:
> >>>So it's basically dm calling into blk_unplug() all the time, which
> >>>doesn't check if the queue is plugged. The reason why I didn't like the
> >>>initial patch is that ->unplug_fn() really should not be called unless
> >>>the queue IS plugged. So how about this instead:
> >>>
> >>>http://git.kernel.dk/?p=linux-2.6-block.git;a=commit;h=c44993018887e82abd49023e92e8d8b6000e03ed
> >>>
> >>>That's a lot more appropriate, imho.
> >>>
> >>>--
> >>>Jens Axboe
> >>
> >>This doesn't seem correct to me. The difference between blk_unplug and
> >>generic_unplug_device is that blk_unplug is called on every type of device
> >>and generic_unplug_device (pointed to by q->unplug_fn) is a method that is
> >>called on low-level disk devices.
> >>
> >>dm and md redefine q->unplug_fn to point to their own method. On dm and
> >>md, blk_unplug is called, but generic_unplug_device is not.
> >>
> >>So if you have this setup
> >>dm-linear(unplugged) -> disk(plugged)
> >>
> >>then, with your patch, a call to blk_unplug(dm-linear) will not unplug the
> >>disk. With my patch, a call to blk_unplug(dm-linear) will unplug the disk
> >>--- it calls q->unplug_fn that points to dm_unplug_all, that calls
> >>blk_unplug again on the disk and that calls generic_unplug_device on disk
> >>queue.
> >
> >That is because the md/dm don't set the plugged flag which I think they
> >should. So we fix that instead so that plugging works the same from the
> >block core or from a driver instead of adding work-arounds in the block
> >unplug handler.
>
> When should dm/md set the plugged flag? It has several disks (or more
> dm/md layers), some of them may be plugged, some not --- furthermore, the
> disk queues are shared by other devices --- there may be more devices on
> different partitions.
>
> So the question: when do you want dm/md to set the plugged bit? Do you
> really want to plug the queue at the top layer and merge requests there?
>
> >Adding a check for plugged in the plug handler is a
> >hack, I don't see how you can argue against that.
>
> I changed generic_unplug_device from:
> spin_lock()
> if (plugged bit is set) unplug...;
> spin_unlock()
>
> to:
> if (plugged bit is set)
> {
> spin_lock()
> if (plugged bit is set) unplug...;
> spin_unlock()
> }
>
> --- I don't see anything wrong with it. At least, the change is so trivial
> that we can be sure that it won't have negative effect on performance.
>
> What you propose is complete rewrite of dm/md plugging mechanism to plug
> the queue and merge requests at upper layer --- the questions are:
>
> - what exactly you are proposing? (plugging at upper layer? lower layer?
> both layers? don't plug and just somehow propagate the plugged bit?)
> - why are you proposing that?
>
> Note that for some dm targets it would be benefical to join the requests
> at upper layer (dm-linear, raid1), for others (raid0, dm-snapshots) it
> damages performance (you merge the requests before passing them to raid0
> and you chop them again to smaller pieces in raid0).
It will indeed get a lot more involved. Sigh. Well I'll apply your patch
to generic_unplug_device(), it's at least a worth while optimization in
the mean time.
--
Jens Axboe
prev parent reply other threads:[~2008-05-07 7:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-29 19:12 [PATCH] Optimize lock in queue unplugging Mikulas Patocka
2008-04-29 19:25 ` Jens Axboe
2008-04-29 20:02 ` Mikulas Patocka
2008-04-29 20:05 ` Jens Axboe
2008-04-29 20:29 ` Mike Anderson
2008-04-30 7:14 ` Jens Axboe
2008-04-30 10:38 ` Alasdair G Kergon
2008-04-30 13:54 ` Mikulas Patocka
2008-05-04 19:11 ` Jens Axboe
2008-05-05 4:01 ` Mikulas Patocka
2008-05-07 7:45 ` Jens Axboe [this message]
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=20080507074556.GQ329@kernel.dk \
--to=jens.axboe@oracle.com \
--cc=agk@redhat.com \
--cc=andmike@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mpatocka@redhat.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