public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


      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