From: "hch@lst.de" <hch@lst.de>
To: "tj@kernel.org" <tj@kernel.org>
Cc: "hch@lst.de" <hch@lst.de>,
Bart Van Assche <Bart.VanAssche@wdc.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"00moses.alexander00@gmail.com" <00moses.alexander00@gmail.com>,
"axboe@kernel.dk" <axboe@kernel.dk>
Subject: Re: [PATCH] block: Ensure that a request queue is dissociated from the cgroup controller
Date: Thu, 12 Apr 2018 15:56:51 +0200 [thread overview]
Message-ID: <20180412135651.GA6181@lst.de> (raw)
In-Reply-To: <20180412134812.GW793541@devbig577.frc2.facebook.com>
On Thu, Apr 12, 2018 at 06:48:12AM -0700, tj@kernel.org wrote:
> > Which sounds like a very good reason not to use a driver controller
> > lock for internals like blkcq.
> >
> > In fact splitting the lock used for synchronizing access to queue
> > fields from the driver controller lock used to synchronize I/O
> > in the legacy path in long overdue.
>
> It'd be probably a lot easier to make sure the shared lock doesn't go
> away till all the request_queues using it go away. The choice is
> between refcnting something which carries the lock and double locking
> in hot paths. Can't think of many downsides of the former approach.
We've stopped sharing request_queues between different devices a while
ago. The problem is just that for legacy devices the driver still controls
the lock life time, and it might be shorter than the queue lifetime.
Note that for blk-mq we basically don't use the queue_lock at all,
and certainly not in the hot path.
next prev parent reply other threads:[~2018-04-12 13:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-12 1:58 [PATCH] block: Ensure that a request queue is dissociated from the cgroup controller Bart Van Assche
2018-04-12 4:20 ` Alexandru Moise
2018-04-12 4:32 ` Alexandru Moise
2018-04-12 4:22 ` Alexandru Moise
2018-04-12 5:34 ` Christoph Hellwig
2018-04-12 11:52 ` Bart Van Assche
2018-04-12 13:14 ` hch
2018-04-12 13:48 ` tj
2018-04-12 13:56 ` hch [this message]
2018-04-12 13:58 ` tj
2018-04-12 14:07 ` tj
2018-04-12 13:51 ` Tejun Heo
2018-04-12 14:09 ` Bart Van Assche
2018-04-12 15:37 ` Tejun Heo
2018-04-12 16:03 ` Bart Van Assche
2018-04-12 16:12 ` tj
2018-04-12 16:29 ` Bart Van Assche
2018-04-12 18:11 ` tj
2018-04-12 18:56 ` Bart Van Assche
2018-04-12 19:09 ` tj
2018-04-12 22:40 ` Bart Van Assche
2018-04-13 15:18 ` tj
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=20180412135651.GA6181@lst.de \
--to=hch@lst.de \
--cc=00moses.alexander00@gmail.com \
--cc=Bart.VanAssche@wdc.com \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=tj@kernel.org \
/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.