From: Mike Snitzer <snitzer@redhat.com>
To: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Cc: dm-devel@redhat.com, linux-kernel@vger.kernel.org,
Jens Axboe <jens.axboe@oracle.com>,
"Jun'ichi Nomura" <j-nomura@ce.jp.nec.com>,
Vivek Goyal <vgoyal@redhat.com>,
Nikanth Karthikesan <knikanth@suse.de>,
Alasdair Kergon <agk@redhat.com>
Subject: Re: [RFC PATCH 2/2] dm: only initialize full request_queue for request-based device
Date: Fri, 14 May 2010 10:08:52 -0400 [thread overview]
Message-ID: <20100514140852.GA10373@redhat.com> (raw)
In-Reply-To: <4BED049C.5040409@ct.jp.nec.com>
On Fri, May 14 2010 at 4:06am -0400,
Kiyoshi Ueda <k-ueda@ct.jp.nec.com> wrote:
> Hi Mike,
>
> On 05/13/2010 12:57 PM +0900, Mike Snitzer wrote:
> > On Wed, May 12 2010 at 4:23am -0400,
> > Kiyoshi Ueda <k-ueda@ct.jp.nec.com> wrote:
> >
> >> Hi Mike,
> >>
> >> On 05/11/2010 10:15 PM +0900, Mike Snitzer wrote:
> >>> It is clear we need to resolve the current full request_queue
> >>> initialization that occurs even for bio-based DM devices.
> >>>
> >>> I believe the 2 patches I posted accomplish this in a stright-forward
> >>> way. We can always improve on it (by looking at what you proposed
> >>> below) but we need a minimlaist fix that doesn't depend on userspace
> >>> LVM2 changes right now.
> >> Humm, OK.
> >> Indeed, showing iosched directory in bio-based device's sysfs is
> >> confusing users actually, and we need something to resolve that soon.
> >> So I don't strongly object to your approach as the first step, as long
> >> as we can accept the risk of the maintenance cost which I mentioned.
> >
> > OK, I understand your concern (especially after having gone through this
> > further over the past couple days). I'm hopeful maintenance will be
> > minimal.
> >
> >> By the way, your current patch has a problem below.
> >> It needs to be fixed at least.
> >
> > Thanks for the review. I've addressed both your points with additional
> > changes (split between 2 patches).
>
> I found another bug; blk_init_allocated_queue() overwrites q->unplug_fn
> with generic one. (Although it's currently harmless for multipath target.)
Thanks again for your review!
Here is a simple incremental fix:
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 5390754..985dd9c 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -1854,6 +1854,17 @@ static const struct block_device_operations dm_blk_dops;
static void dm_wq_work(struct work_struct *work);
static void dm_rq_barrier_work(struct work_struct *work);
+static void dm_init_md_queue(struct mapped_device *md)
+{
+ md->queue->queuedata = md;
+ md->queue->backing_dev_info.congested_fn = dm_any_congested;
+ md->queue->backing_dev_info.congested_data = md;
+ blk_queue_make_request(md->queue, dm_request);
+ blk_queue_bounce_limit(md->queue, BLK_BOUNCE_ANY);
+ md->queue->unplug_fn = dm_unplug_all;
+ blk_queue_merge_bvec(md->queue, dm_merge_bvec);
+}
+
/*
* Allocate and initialise a blank device with a given minor.
*/
@@ -1895,13 +1906,7 @@ static struct mapped_device *alloc_dev(int minor)
if (!md->queue)
goto bad_queue;
- md->queue->queuedata = md;
- md->queue->backing_dev_info.congested_fn = dm_any_congested;
- md->queue->backing_dev_info.congested_data = md;
- blk_queue_make_request(md->queue, dm_request);
- blk_queue_bounce_limit(md->queue, BLK_BOUNCE_ANY);
- md->queue->unplug_fn = dm_unplug_all;
- blk_queue_merge_bvec(md->queue, dm_merge_bvec);
+ dm_init_md_queue(md);
md->disk = alloc_disk(1);
if (!md->disk)
@@ -1974,7 +1979,7 @@ int dm_init_request_based_queue(struct mapped_device *md)
return 0;
md->queue = q;
md->saved_make_request_fn = md->queue->make_request_fn;
- blk_queue_make_request(md->queue, dm_request);
+ dm_init_md_queue(md);
register_elevator = 1;
} else if (dm_bio_based_md(md)) {
/*
> I feel your patch-set is growing and becoming complex fix rather than
> minimalist/simple fix.
Seems the numerous patches I've posted over the past couple days have
given a false impression. But I do understand your concern.
The longer-term direction you want to take DM (known type during
alloc_dev) illustrates that we share a common goal: only do the precise
work that is needed to initialize the request_queue for a DM device
(whether it is bio-based or request-based).
My changes do accomplish that in the near-term without requiring
userspace change. Many of my proposed changes are just refactoring
existing code to clearly split out what is needed for request-based vs
bio-based.
I'll post a single patch that contains my changes (no need to have 2
patches any more). With that patch I'm hopeful you'll see my changes
aren't as complex as they might have seemed over the past few days.
> I think touching mapped_device/queue at table loading time makes
> things complex. It is natural that table's arguments are reflected
> to mapped_device/queue at table binding time instead.
>
> > I confirmed with Alasdair that we don't want to conditionally relax DM's
> > allocation constraints for request-based DM. Best to be consistent
> > about not allowing allocations during resume.
>
> OK.
> Then, how about the patch below?
> It still fully initializes queue at device creation time for both
> bio-based and request-based. Then, it drops elevator when the device
> type is decided as bio-based at table binding time.
> So no memory allocation during resume (freeing instead).
I'm inclined to believe that the extra work for bio-based DM is not
ideal. And even freeing during resume _could_ pose a problem during a
resume (if it triggers unknown additional housekeeping).
elv_unregister_queue() and elevator_exit() do quite a bit more than
simply freeing memory. We can't safely assume those methods will never
allocate memory to accomplish their cleanup (now or in the future).
> I hope this simple work-around approach is acceptable for you and
> Alasdair (and others).
While it is certainly a small change it carries with it the disadvantage
of still requiring more work than is needed for bio-based request_queue
initialization. It also poses a risk by requiring additional work when
resuming a bio-based device.
> (Then, let's focus on making a right fix rather than hacking
> the block layer.)
I haven't been hacking the block layer. Please don't misrepresent what
I proposed.
Regards,
Mike
next prev parent reply other threads:[~2010-05-14 14:09 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-10 22:55 [RFC PATCH 1/2] block: allow initialization of previously allocated request_queue Mike Snitzer
2010-05-10 22:55 ` [RFC PATCH 2/2] dm: only initialize full request_queue for request-based device Mike Snitzer
2010-05-11 4:23 ` Kiyoshi Ueda
2010-05-11 13:15 ` Mike Snitzer
2010-05-12 8:23 ` Kiyoshi Ueda
2010-05-13 3:57 ` Mike Snitzer
2010-05-14 8:06 ` Kiyoshi Ueda
2010-05-14 14:08 ` Mike Snitzer [this message]
2010-05-17 9:27 ` Kiyoshi Ueda
2010-05-17 17:27 ` Mike Snitzer
2010-05-18 8:32 ` Kiyoshi Ueda
2010-05-18 13:46 ` Mike Snitzer
2010-05-19 5:57 ` Kiyoshi Ueda
2010-05-19 12:01 ` Mike Snitzer
2010-05-19 14:39 ` Mike Snitzer
2010-05-19 14:45 ` Mike Snitzer
2010-05-20 11:21 ` Kiyoshi Ueda
2010-05-20 17:07 ` Mike Snitzer
2010-05-21 8:32 ` Kiyoshi Ueda
2010-05-21 13:34 ` Mike Snitzer
2010-05-24 9:58 ` Kiyoshi Ueda
2010-05-19 21:51 ` Mike Snitzer
2010-05-13 4:31 ` [PATCH 2/2 v2] " Mike Snitzer
2010-05-13 5:02 ` [RFC PATCH 3/2] dm: bio-based device must not register elevator in sysfs Mike Snitzer
2010-05-13 22:14 ` [PATCH 3/2 v2] " Mike Snitzer
2010-05-11 6:55 ` [RFC PATCH 1/2] block: allow initialization of previously allocated request_queue Jens Axboe
2010-05-11 13:18 ` Mike Snitzer
2010-05-11 13:21 ` Jens Axboe
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=20100514140852.GA10373@redhat.com \
--to=snitzer@redhat.com \
--cc=agk@redhat.com \
--cc=dm-devel@redhat.com \
--cc=j-nomura@ce.jp.nec.com \
--cc=jens.axboe@oracle.com \
--cc=k-ueda@ct.jp.nec.com \
--cc=knikanth@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=vgoyal@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;
as well as URLs for NNTP newsgroup(s).