public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nikanth Karthikesan <knikanth@suse.de>
To: Mike Snitzer <snitzer@redhat.com>
Cc: Jens Axboe <jens.axboe@oracle.com>,
	Alasdair G Kergon <agk@redhat.com>,
	Kiyoshi Ueda <k-ueda@ct.jp.nec.com>,
	dm-devel@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] Initialize mempool and elevator only for request-based dm devices
Date: Mon, 10 Aug 2009 15:51:11 +0530	[thread overview]
Message-ID: <200908101551.12047.knikanth@suse.de> (raw)
In-Reply-To: <20090808162156.GA7432@redhat.com>

On Saturday 08 August 2009 21:51:59 Mike Snitzer wrote:
> On Sat, Aug 08 2009 at 12:56am -0400,
>
> Nikanth Karthikesan <knikanth@suse.de> wrote:
> > Intialize the request_queue and elevator only when the device is marked
> > as a request-based device. This avoids unnecessary creation of mempool
> > for requests. Also we wrongly initialize the elevator even for bio-based
> > devices. As the /sys/block/dm-*/queue/scheduler is exported for
> > device-mapper devices, it is possible to confuse with scheduler options
> > for bio-based devices where scheduler is not at all used.
> >
> > Signed-off-by: Nikanth Karthikesan <knikanth@suse.de>
>
> I like how this clearly splits out request-based DM queue initialization.
>

Thanks.

> More comments below.
>
> > diff --git a/drivers/md/dm.c b/drivers/md/dm.c
> > index 8a311ea..b01dfbe 100644
> > --- a/drivers/md/dm.c
> > +++ b/drivers/md/dm.c
> > @@ -2203,7 +2199,25 @@ int dm_swap_table(struct mapped_device *md, struct
> > dm_table *table) goto out;
> >  	}
> >
> > -	__unbind(md);
> > +	if (md->map)
> > +		__unbind(md);
> > +	else {
> > +	/* new device is being marked as either request-based or bio-based */
> > +		if (dm_table_request_based(table)) {
> > +			/* Initialize queue for request-based dm */
> > +			r = blk_init_allocated_queue(md->queue, dm_request_fn,
> > +								 NULL);
> > +			if (r)
> > +				goto out;
> > +			md->saved_make_request_fn = md->queue->make_request_fn;
> > +			blk_queue_make_request(md->queue, dm_request);
>
> This blk_queue_make_request() is redundant as it was already established
> in alloc_dev().  The fact that its behavior is now altered as a result
> of the md->saved_make_request_fn assignment doesn't change the fact that
> the queue will be using dm_request().  Am I missing something?
>

blk_init_allocated_queue() would reset it to __make_request(). So we need to 
initialize it again. I would add a comment in v2 of the patch.

> Also, I think the code should be cleaned up as follows:
>
> diff --git a/drivers/md/dm.c b/drivers/md/dm.c
> index b01dfbe..1b8aa43 100644
> --- a/drivers/md/dm.c
> +++ b/drivers/md/dm.c
> @@ -2199,25 +2199,18 @@ int dm_swap_table(struct mapped_device *md, struct
> dm_table *table) goto out;
>  	}
>
> -	if (md->map)
> -		__unbind(md);
> -	else {
> -	/* new device is being marked as either request-based or bio-based */
> -		if (dm_table_request_based(table)) {
> -			/* Initialize queue for request-based dm */
> -			r = blk_init_allocated_queue(md->queue, dm_request_fn,
> -								 NULL);
> -			if (r)
> -				goto out;
> -			md->saved_make_request_fn = md->queue->make_request_fn;
> -			blk_queue_make_request(md->queue, dm_request);
> -			blk_queue_softirq_done(md->queue, dm_softirq_done);
> -			blk_queue_prep_rq(md->queue, dm_prep_fn);
> -			blk_queue_lld_busy(md->queue, dm_lld_busy);
> -
> -		}
> +	if (!md->map && dm_table_request_based(table)) {
> +		/* Initialize queue for request-based dm */
> +		r = blk_init_allocated_queue(md->queue, dm_request_fn, NULL);
> +		if (r)
> +			goto out;
> +		md->saved_make_request_fn = md->queue->make_request_fn;
> +		blk_queue_softirq_done(md->queue, dm_softirq_done);
> +		blk_queue_prep_rq(md->queue, dm_prep_fn);
> +		blk_queue_lld_busy(md->queue, dm_lld_busy);
>  	}
>
> +	__unbind(md);
>  	r = __bind(md, table, &limits);
>
>  out:

I thought of this. But personally, I did not prefer this, as this makes it 
clear that we do __unbind() only on not new devices. But, yes it needs more 
level of nesting and looks ugly. Changed in v2 of the patch.

Thanks
Nikanth


  reply	other threads:[~2009-08-10 10:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-08  4:56 [PATCH 2/2] Initialize mempool and elevator only for request-based dm devices Nikanth Karthikesan
2009-08-08 16:21 ` Mike Snitzer
2009-08-10 10:21   ` Nikanth Karthikesan [this message]
2009-08-10 10:48     ` [PATCH-v2 " Nikanth Karthikesan
2009-08-11  8:06       ` Kiyoshi Ueda
2009-08-11  9:05         ` Nikanth Karthikesan
2009-08-11  9:32           ` [PATCH-v3 " Nikanth Karthikesan
2009-08-12  2:15           ` [PATCH-v2 " Kiyoshi Ueda
2009-08-12  8:47             ` Nikanth Karthikesan
2009-08-14  7:01               ` Kiyoshi Ueda
2010-05-11 16:23                 ` Mike Snitzer

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=200908101551.12047.knikanth@suse.de \
    --to=knikanth@suse.de \
    --cc=agk@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=jens.axboe@oracle.com \
    --cc=k-ueda@ct.jp.nec.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=snitzer@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