public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Juri Lelli <juri.lelli@redhat.com>
Cc: Aaron Tomlin <atomlin@atomlin.com>,
	linux-kernel@vger.kernel.org, jiangshanlai@gmail.com,
	peterz@infradead.org
Subject: Re: [RFC PATCH 0/2] workqueue: Introduce PF_WQ_RESCUE_WORKER
Date: Mon, 11 Dec 2023 08:39:48 -1000	[thread overview]
Message-ID: <ZXdXdBzvbkI4Y4fL@slm.duckdns.org> (raw)
In-Reply-To: <um77hym4t6zyypfbhwbaeqxpfdzc657oa7vgowdfah7cuctjak@pexots3mfb24>

Hello,

On Mon, Dec 11, 2023 at 03:51:57PM +0100, Juri Lelli wrote:
> Guess this is a requirement because, if workqueue processing is stuck
> for some reason, getting rescuers to run on the same set of cpus
> workqueues have been restricted to already doesn't really have good
> chances of making any progress?

The only problem rescuers try to solve is deadlocks caused by lack of
memory, so on the cpu side, it just follows whatever worker pool it's trying
to help.

> Wonder if we still might need some sort of fail hard/warn mode in case
> strict isolation is in place? Or maybe we have that already?

For both percpu and unbound workqueues, the rescuers just follow whatever
pool it's trying to help at the moment, so it shouldn't cause any surprises
in terms of isolation. It just temporarily joins the already active but
stuck pool.

Thanks.

-- 
tejun

  reply	other threads:[~2023-12-11 18:39 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-29 13:53 [RFC PATCH 0/2] workqueue: Introduce PF_WQ_RESCUE_WORKER Aaron Tomlin
2023-07-29 13:53 ` [RFC PATCH 1/2] " Aaron Tomlin
2023-07-29 16:07   ` Peter Zijlstra
2023-08-01 10:04     ` Aaron Tomlin
2023-07-29 13:53 ` [RFC PATCH 2/2] workqueue: Simplify current_is_workqueue_rescuer() Aaron Tomlin
2023-07-31 23:35 ` [RFC PATCH 0/2] workqueue: Introduce PF_WQ_RESCUE_WORKER Tejun Heo
2023-08-01 10:53   ` Aaron Tomlin
2023-08-02 18:10     ` Tejun Heo
2023-08-03 20:19       ` Aaron Tomlin
2023-08-03 20:34         ` Tejun Heo
2023-08-05 23:45           ` Aaron Tomlin
2023-12-11 14:51 ` Juri Lelli
2023-12-11 18:39   ` Tejun Heo [this message]
2023-12-12  9:56     ` Juri Lelli
2023-12-12 17:14       ` Tejun Heo
2023-12-12 19:06         ` Aaron Tomlin
2023-12-12 20:16           ` Tejun Heo
2023-12-13  8:59         ` Juri Lelli
2023-12-13 15:35           ` Tejun Heo
2023-12-13 18:32             ` Juri Lelli
2023-12-13 18:38               ` Tejun Heo
2023-12-14 11:25                 ` Juri Lelli
2023-12-14 19:47                   ` Tejun Heo
2023-12-15  6:50                     ` Juri Lelli
2023-12-19  8:55                       ` Juri Lelli

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=ZXdXdBzvbkI4Y4fL@slm.duckdns.org \
    --to=tj@kernel.org \
    --cc=atomlin@atomlin.com \
    --cc=jiangshanlai@gmail.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.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