From: Jason Gunthorpe <jgg@ziepe.ca>
To: Daniel Wagner <dwagner@suse.de>
Cc: linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@fb.com>,
Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
Steve Wise <swise@opengridcomputing.com>,
Leon Romanovsky <leon@kernel.org>,
Potnuri Bharat Teja <bharat@chelsio.com>
Subject: Re: [PATCH] nvme: Drop WQ_MEM_RECLAIM flag from core workqueues
Date: Mon, 12 Apr 2021 09:31:49 -0300 [thread overview]
Message-ID: <20210412123149.GE227011@ziepe.ca> (raw)
In-Reply-To: <20210412122330.5166-1-dwagner@suse.de>
On Mon, Apr 12, 2021 at 02:23:30PM +0200, Daniel Wagner wrote:
> Drop the WQ_MEM_RECLAIM flag as it is not needed and introduces
> warnings.
>
> The documentation says "all wq which might be used in the memory
> reclaim paths MUST have this flag set. The wq is guaranteed to have at
> least one execution context regardless of memory pressure."
>
> By setting WQ_MEM_RECLAIM the threads are ready be running during
> early init. The claim it guarantees at least one execution context
> regardless of memory pressure is not supported by the implementation.
>
> As the nvme core does not depend on early init we can remove the
> WQ_MEM_RECLAIM flag. This resolves a warning in the rdma path:
What does early init have to do with WQ_MEM_RECLAIM?
WQ_MEM_RECLIAM is required when any thread in a reclaim context goes
to sleep waiting for a WQ to complete. For instance by calling
flush_workqueue() or many other things.
The sleeping reclaim context must be guarenteed that the work can be
completed without the work, work queue machinery, or anything the work
has become interconnected with, recursing back into a reclaim.
IIRC the issue here was some destroy or flush work in some error
condition that happened to be under a reclaim context?
I don't see the kind of analysis I'd expect in this commit message to
justify this change.
Jason
next prev parent reply other threads:[~2021-04-12 12:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-12 12:23 [PATCH] nvme: Drop WQ_MEM_RECLAIM flag from core workqueues Daniel Wagner
2021-04-12 12:31 ` Jason Gunthorpe [this message]
2021-04-12 12:49 ` Daniel Wagner
2021-04-12 13:04 ` Jason Gunthorpe
2021-04-13 8:54 ` Daniel Wagner
2021-04-13 13:35 ` Jason Gunthorpe
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=20210412123149.GE227011@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=axboe@fb.com \
--cc=bharat@chelsio.com \
--cc=dwagner@suse.de \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--cc=swise@opengridcomputing.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).