From: Nikanth Karthikesan <knikanth@suse.de>
To: Mike Snitzer <snitzer@redhat.com>
Cc: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>,
dm-devel@redhat.com, linux-kernel@vger.kernel.org,
Alasdair G Kergon <agk@redhat.com>,
Jens Axboe <jens.axboe@oracle.com>
Subject: Re: [PATCH 1/2] Allow delaying initialization of queue after allocation
Date: Mon, 10 Aug 2009 15:51:07 +0530 [thread overview]
Message-ID: <200908101551.08605.knikanth@suse.de> (raw)
In-Reply-To: <20090808154240.GA7036@redhat.com>
On Saturday 08 August 2009 21:12:40 Mike Snitzer wrote:
> On Sat, Aug 08 2009 at 12:55am -0400,
>
> Nikanth Karthikesan <knikanth@suse.de> wrote:
> > Export a way to delay initializing a request_queue after allocating it.
> > This is needed by device-mapper devices, as they create the queue on
> > device creation time, but they decide whether it would use the elevator
> > and requests only after first successful table load. Only request-based
> > dm-devices use the elevator and requests. Without this either one needs
> > to initialize and free the mempool and elevator, if it was a bio-based
> > dm-device or leave it allocated, as it is currently done.
> >
> > Signed-off-by: Nikanth Karthikesan <knikanth@suse.de>
>
> This patch needed to be refreshed to account for the changes from this
> recent commit: a4e7d46407d73f35d217013b363b79a8f8eafcaa
>
> I've attached a refreshed patch.
>
Thanks.
> Though I still have questions/feedback below.
>
> > diff --git a/block/blk-core.c b/block/blk-core.c
> > index 4b45435..5db0772 100644
> > --- a/block/blk-core.c
> > +++ b/block/blk-core.c
> > @@ -569,12 +571,25 @@ blk_init_queue_node(request_fn_proc *rfn,
> > spinlock_t *lock, int node_id) if (!q)
> > return NULL;
> >
> > - q->node = node_id;
> > - if (blk_init_free_list(q)) {
> > + if (blk_init_allocated_queue(q, rfn, lock)) {
> > + blk_put_queue(q);
> > kmem_cache_free(blk_requestq_cachep, q);
> > return NULL;
> > }
> >
> > + return q;
> > +}
> > +EXPORT_SYMBOL(blk_init_queue_node);
> > +
> > +int blk_init_allocated_queue(struct request_queue *q, request_fn_proc
> > *rfn, + spinlock_t *lock)
> > +{
> > + int err = 0;
> > +
> > + err = blk_init_free_list(q);
> > + if (err)
> > + goto out;
> > +
> > /*
> > * if caller didn't supply a lock, they get per-queue locking with
> > * our embedded lock
> > @@ -598,15 +613,20 @@ blk_init_queue_node(request_fn_proc *rfn,
> > spinlock_t *lock, int node_id) /*
> > * all done
> > */
> > - if (!elevator_init(q, NULL)) {
> > - blk_queue_congestion_threshold(q);
> > - return q;
> > - }
> > + err = elevator_init(q, NULL);
> > + if (err)
> > + goto free_and_out;
> >
> > - blk_put_queue(q);
> > - return NULL;
> > + blk_queue_congestion_threshold(q);
> > +
> > + return 0;
> > +
> > +free_and_out:
> > + mempool_destroy(q->rq.rq_pool);
> > +out:
> > + return err;
> > }
> > -EXPORT_SYMBOL(blk_init_queue_node);
> > +EXPORT_SYMBOL(blk_init_allocated_queue);
> >
> > int blk_get_queue(struct request_queue *q)
> > {
>
> In the previous code blk_init_queue_node() only called blk_put_queue()
> iff elevator_init() failed.
>
> Why is blk_init_queue_node() now always calling blk_put_queue() on an
> error from blk_init_allocated_queue()? It could be that
> blk_init_free_list() was what failed and not elevator_init().
>
I think, it was a bug on not calling blk_put_queue() even when
blk_init_free_list() failed which would be fixed now.
> I'd imagine it is because some callers of blk_init_allocated_queue(),
> e.g. DM, must not have the queue's refcount dropped on failure? A
> comment on _why_ would really help set the caller's expectations. Maybe
> at the top of blk_init_allocated_queue()? E.g.:
>
> "It is up to the caller to manage the allocated queue's lifecycle
> relative to blk_init_allocated_queue() failure". I guess that is
> obvious after having reviewed this but...
>
> Also, a comment that blk_init_allocated_queue()'s mempool_destroy() is
> to "cleanup the mempool allocated via blk_init_free_list()" would help.
>
Will add the comment when I resend the patch.
Thanks for reviewing.
Thanks
Nikanth
WARNING: multiple messages have this Message-ID (diff)
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 1/2] Allow delaying initialization of queue after allocation
Date: Mon, 10 Aug 2009 15:51:07 +0530 [thread overview]
Message-ID: <200908101551.08605.knikanth@suse.de> (raw)
In-Reply-To: <20090808154240.GA7036@redhat.com>
On Saturday 08 August 2009 21:12:40 Mike Snitzer wrote:
> On Sat, Aug 08 2009 at 12:55am -0400,
>
> Nikanth Karthikesan <knikanth@suse.de> wrote:
> > Export a way to delay initializing a request_queue after allocating it.
> > This is needed by device-mapper devices, as they create the queue on
> > device creation time, but they decide whether it would use the elevator
> > and requests only after first successful table load. Only request-based
> > dm-devices use the elevator and requests. Without this either one needs
> > to initialize and free the mempool and elevator, if it was a bio-based
> > dm-device or leave it allocated, as it is currently done.
> >
> > Signed-off-by: Nikanth Karthikesan <knikanth@suse.de>
>
> This patch needed to be refreshed to account for the changes from this
> recent commit: a4e7d46407d73f35d217013b363b79a8f8eafcaa
>
> I've attached a refreshed patch.
>
Thanks.
> Though I still have questions/feedback below.
>
> > diff --git a/block/blk-core.c b/block/blk-core.c
> > index 4b45435..5db0772 100644
> > --- a/block/blk-core.c
> > +++ b/block/blk-core.c
> > @@ -569,12 +571,25 @@ blk_init_queue_node(request_fn_proc *rfn,
> > spinlock_t *lock, int node_id) if (!q)
> > return NULL;
> >
> > - q->node = node_id;
> > - if (blk_init_free_list(q)) {
> > + if (blk_init_allocated_queue(q, rfn, lock)) {
> > + blk_put_queue(q);
> > kmem_cache_free(blk_requestq_cachep, q);
> > return NULL;
> > }
> >
> > + return q;
> > +}
> > +EXPORT_SYMBOL(blk_init_queue_node);
> > +
> > +int blk_init_allocated_queue(struct request_queue *q, request_fn_proc
> > *rfn, + spinlock_t *lock)
> > +{
> > + int err = 0;
> > +
> > + err = blk_init_free_list(q);
> > + if (err)
> > + goto out;
> > +
> > /*
> > * if caller didn't supply a lock, they get per-queue locking with
> > * our embedded lock
> > @@ -598,15 +613,20 @@ blk_init_queue_node(request_fn_proc *rfn,
> > spinlock_t *lock, int node_id) /*
> > * all done
> > */
> > - if (!elevator_init(q, NULL)) {
> > - blk_queue_congestion_threshold(q);
> > - return q;
> > - }
> > + err = elevator_init(q, NULL);
> > + if (err)
> > + goto free_and_out;
> >
> > - blk_put_queue(q);
> > - return NULL;
> > + blk_queue_congestion_threshold(q);
> > +
> > + return 0;
> > +
> > +free_and_out:
> > + mempool_destroy(q->rq.rq_pool);
> > +out:
> > + return err;
> > }
> > -EXPORT_SYMBOL(blk_init_queue_node);
> > +EXPORT_SYMBOL(blk_init_allocated_queue);
> >
> > int blk_get_queue(struct request_queue *q)
> > {
>
> In the previous code blk_init_queue_node() only called blk_put_queue()
> iff elevator_init() failed.
>
> Why is blk_init_queue_node() now always calling blk_put_queue() on an
> error from blk_init_allocated_queue()? It could be that
> blk_init_free_list() was what failed and not elevator_init().
>
I think, it was a bug on not calling blk_put_queue() even when
blk_init_free_list() failed which would be fixed now.
> I'd imagine it is because some callers of blk_init_allocated_queue(),
> e.g. DM, must not have the queue's refcount dropped on failure? A
> comment on _why_ would really help set the caller's expectations. Maybe
> at the top of blk_init_allocated_queue()? E.g.:
>
> "It is up to the caller to manage the allocated queue's lifecycle
> relative to blk_init_allocated_queue() failure". I guess that is
> obvious after having reviewed this but...
>
> Also, a comment that blk_init_allocated_queue()'s mempool_destroy() is
> to "cleanup the mempool allocated via blk_init_free_list()" would help.
>
Will add the comment when I resend the patch.
Thanks for reviewing.
Thanks
Nikanth
next prev parent reply other threads:[~2009-08-10 10:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-08 4:55 [PATCH 1/2] Allow delaying initialization of queue after allocation Nikanth Karthikesan
2009-08-08 4:55 ` Nikanth Karthikesan
2009-08-08 15:42 ` Mike Snitzer
2009-08-08 15:42 ` Mike Snitzer
2009-08-08 16:42 ` Mike Snitzer
2009-08-10 10:21 ` Nikanth Karthikesan [this message]
2009-08-10 10:21 ` Nikanth Karthikesan
2009-08-10 10:48 ` [PATCH-v2 " Nikanth Karthikesan
2009-08-10 10:48 ` Nikanth Karthikesan
2009-08-11 9:32 ` [PATCH-v3 " Nikanth Karthikesan
2009-08-11 9:32 ` Nikanth Karthikesan
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.08605.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.