linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Wagner <dwagner@suse.de>
To: Jason Gunthorpe <jgg@ziepe.ca>
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 14:49:09 +0200	[thread overview]
Message-ID: <20210412124909.olui5hfhceakt4u4@beryllium.lan> (raw)
In-Reply-To: <20210412123149.GE227011@ziepe.ca>

Hi Jason,

On Mon, Apr 12, 2021 at 09:31:49AM -0300, Jason Gunthorpe wrote:
> What does early init have to do with WQ_MEM_RECLAIM?

40c17f75dfa9 ("workqueue: allow WQ_MEM_RECLAIM on early init workqueues")

    Workqueues can be created early during boot before workqueue subsystem
    in fully online - work items are queued waiting for later full
    initialization.  However, early init wasn't supported for
    WQ_MEM_RECLAIM workqueues causing unnecessary annoyances for a subset
    of users.  Expand early init support to include WQ_MEM_RECLAIM
    workqueues.

That's the connection between WQ_MEM_RECLAIM and early init.

> 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 understand what you are saying and I would totally agree with you but
where is the code for this?

I've grepped through the code and didn't find anything which supports
the guarantee claim. Neither mm nor schedule seems to care about this
flag nor workqueue.c (except the early init bits). Or I must miss
something.

Thanks,
Daniel



  reply	other threads:[~2021-04-12 12:49 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
2021-04-12 12:49   ` Daniel Wagner [this message]
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=20210412124909.olui5hfhceakt4u4@beryllium.lan \
    --to=dwagner@suse.de \
    --cc=axboe@fb.com \
    --cc=bharat@chelsio.com \
    --cc=hch@lst.de \
    --cc=jgg@ziepe.ca \
    --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).