From: Tejun Heo <tj@kernel.org>
To: Mike Snitzer <snitzer@kernel.org>
Cc: Eric Biggers <ebiggers@kernel.org>,
Mikulas Patocka <mpatocka@redhat.com>,
dm-devel@lists.linux.dev, Alasdair Kergon <agk@redhat.com>,
Lai Jiangshan <jiangshanlai@gmail.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Sami Tolvanen <samitolvanen@google.com>,
linux-nfs@vger.kernel.org
Subject: Re: sharing rescuer threads when WQ_MEM_RECLAIM needed? [was: Re: dm verity: don't use WQ_MEM_RECLAIM]
Date: Thu, 5 Sep 2024 15:34:27 -1000 [thread overview]
Message-ID: <ZtpcI-Qv_Q6g0Q6Z@slm.duckdns.org> (raw)
In-Reply-To: <ZtpATbuopBFAzl89@kernel.org>
Hello,
On Thu, Sep 05, 2024 at 07:35:41PM -0400, Mike Snitzer wrote:
...
> > I wonder if there's any way to safely share the rescuer threads.
>
> Oh, I like that idea, yes please! (would be surprised if it exists,
> but I love being surprised!). Like Mikulas pointed out, we have had
> to deal with fundamental deadlocks due to resource sharing in DM.
> Hence the need for guaranteed forward progress that only
> WQ_MEM_RECLAIM can provide.
The most straightforward way to do this would be simply sharing the
workqueue across the entities that wanna be in the same forward progress
guarantee domain. It shouldn't be that difficult to make workqueues share a
rescuer either but may be a bit of an overkill.
Taking a step back tho, how would you determine which ones can share a
rescuer? Things which stack on top of each other can't share the rescuer cuz
higher layer occupying the rescuer and stall lower layers and thus deadlock.
The rescuers can be shared across independent stacks of dm devices but that
sounds like that will probably involve some graph walking. Also, is this a
real problem?
Thanks.
--
tejun
next prev parent reply other threads:[~2024-09-06 1:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-04 4:04 [PATCH] dm verity: don't use WQ_MEM_RECLAIM Eric Biggers
2024-09-05 14:32 ` Mike Snitzer
2024-09-05 18:21 ` [PATCH] " Mikulas Patocka
2024-09-05 22:35 ` Eric Biggers
2024-09-05 23:35 ` sharing rescuer threads when WQ_MEM_RECLAIM needed? [was: Re: dm verity: don't use WQ_MEM_RECLAIM] Mike Snitzer
2024-09-06 1:34 ` Tejun Heo [this message]
2024-09-06 11:23 ` Mikulas Patocka
2024-09-06 10:59 ` [PATCH] dm verity: don't use WQ_MEM_RECLAIM Mikulas Patocka
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=ZtpcI-Qv_Q6g0Q6Z@slm.duckdns.org \
--to=tj@kernel.org \
--cc=agk@redhat.com \
--cc=dm-devel@lists.linux.dev \
--cc=ebiggers@kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nfs@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=samitolvanen@google.com \
--cc=snitzer@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox