[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111019172914.GI1140@redhat.com>
Date: Wed, 19 Oct 2011 13:29:14 -0400
From: Vivek Goyal <vgoyal@...hat.com>
To: Tejun Heo <tj@...nel.org>
Cc: axboe@...nel.dk, linux-kernel@...r.kernel.org, ctalbott@...gle.com
Subject: Re: [PATCH 10/10] block: fix request_queue lifetime handling by
making blk_queue_cleanup() proper shutdown
On Wed, Oct 19, 2011 at 10:12:59AM -0700, Tejun Heo wrote:
> Hello,
>
> On Wed, Oct 19, 2011 at 12:18:40PM -0400, Vivek Goyal wrote:
> > > diff --git a/block/blk-throttle.c b/block/blk-throttle.c
> > > index 900a0c9..8edb949 100644
> > > --- a/block/blk-throttle.c
> > > +++ b/block/blk-throttle.c
> > > @@ -309,6 +309,10 @@ static struct throtl_grp * throtl_get_tg(struct throtl_data *td)
> > > struct blkio_cgroup *blkcg;
> > > struct request_queue *q = td->queue;
> > >
> > > + /* no throttling for dead queue */
> > > + if (unlikely(test_bit(QUEUE_FLAG_DEAD, &q->queue_flags)))
> > > + return NULL;
> > > +
> >
> > May be blk_throtl_bio() is probably a better place to do this check, just
> > before callig throtl_get_tg().
>
> Hmmm... the thing is you need to check DEAD again once after releasing
> and re-grabbing the queuelock, os if we move the test into the caller,
> we end up having one in the caller and one in the callee, so I thought
> it would be better to keep them in the same function.
Sorry I did not get that why do we need to check again for DEAD after
realeasing the queue lock. From throttling perspective, we grab lock
once, if queue is DEAD, release lock and just return.
blk_throtl_bio() {
bunch_of_checks_without_queue_lock;
spin_lock()
if (queue_dead) {
spin_unlock()
return;
}
throtl_get_tg();
}
> My opinion on
> it isn't too strong tho. If you feel strong about it, please feel
> free to move it.
No, this is a minor nit. Probably will change it sometime in future as part
of some other work in blk-throttle.
Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists