From: Frederic Weisbecker <frederic@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>,
Michal Hocko <mhocko@kernel.org>,
Vlastimil Babka <vbabka@suse.cz>,
"Paul E. McKenney" <paulmck@kernel.org>,
Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
Joel Fernandes <joel@joelfernandes.org>,
Boqun Feng <boqun.feng@gmail.com>,
Zqiang <qiang.zhang1211@gmail.com>,
Uladzislau Rezki <urezki@gmail.com>,
rcu@vger.kernel.org, Michal Hocko <mhocko@suse.com>
Subject: Re: [PATCH 11/20] sched: Handle CPU isolation on last resort fallback rq selection
Date: Tue, 8 Oct 2024 14:27:58 +0200 [thread overview]
Message-ID: <ZwUlTiDpvmb9ysfn@localhost.localdomain> (raw)
In-Reply-To: <20241008105434.GA9243@willie-the-truck>
Le Tue, Oct 08, 2024 at 11:54:35AM +0100, Will Deacon a écrit :
> On Fri, Sep 27, 2024 at 12:48:59AM +0200, Frederic Weisbecker wrote:
> > When a kthread or any other task has an affinity mask that is fully
> > offline or unallowed, the scheduler reaffines the task to all possible
> > CPUs as a last resort.
> >
> > This default decision doesn't mix up very well with nohz_full CPUs that
> > are part of the possible cpumask but don't want to be disturbed by
> > unbound kthreads or even detached pinned user tasks.
> >
> > Make the fallback affinity setting aware of nohz_full. This applies to
> > all architectures supporting nohz_full except arm32. However this
> > architecture that overrides the task possible mask is unlikely to be
> > willing to integrate new development.
>
> I'm not sure I understand this last sentence. The possible mask is
> overridden for 32-bit tasks on an *arm64* kernel when running on an SoC
> featuring some CPUs that can execute only 64-bit tasks. Who is unwilling
> to integrate what?
Right I've been lazy on that, assuming that nohz_full is a niche, and
nohz_full on arm 32 bits tasks must be even more a niche. But I can make
it a macro just like task_cpu_possible_mask() so that architectures
can override it?
Thanks.
next prev parent reply other threads:[~2024-10-08 12:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240926224910.11106-1-frederic@kernel.org>
2024-09-26 22:48 ` [PATCH 11/20] sched: Handle CPU isolation on last resort fallback rq selection Frederic Weisbecker
2024-09-27 7:26 ` Michal Hocko
2024-10-08 10:54 ` Will Deacon
2024-10-08 12:27 ` Frederic Weisbecker [this message]
2024-10-15 13:48 ` Frederic Weisbecker
2024-10-28 16:25 ` Will Deacon
2024-10-28 16:51 ` Frederic Weisbecker
2024-10-28 16:54 ` [PATCH 1/2] arm64: Keep first mismatched 32bits el0 capable CPU online through its callbacks Frederic Weisbecker
2024-10-28 16:56 ` [PATCH 2/2] sched,arm64: Handle CPU isolation on last resort fallback rq selection Frederic Weisbecker
2024-09-26 22:49 ` [PATCH 12/20] kthread: Make sure kthread hasn't started while binding it Frederic Weisbecker
2024-09-26 22:49 ` [PATCH 13/20] kthread: Default affine kthread to its preferred NUMA node Frederic Weisbecker
2024-09-26 22:49 ` [PATCH 16/20] kthread: Implement preferred affinity Frederic Weisbecker
2024-09-26 22:49 ` [PATCH 17/20] rcu: Use kthread preferred affinity for RCU boost Frederic Weisbecker
2024-09-26 22:49 ` [PATCH 18/20] kthread: Unify kthread_create_on_cpu() and kthread_create_worker_on_cpu() automatic format Frederic Weisbecker
2024-09-26 22:49 ` [PATCH 19/20] treewide: Introduce kthread_run_worker[_on_cpu]() Frederic Weisbecker
2024-09-27 5:39 ` Paul E. McKenney
2024-09-26 22:49 ` [PATCH 20/20] rcu: Use kthread preferred affinity for RCU exp kworkers Frederic Weisbecker
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=ZwUlTiDpvmb9ysfn@localhost.localdomain \
--to=frederic@kernel.org \
--cc=boqun.feng@gmail.com \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.com \
--cc=neeraj.upadhyay@kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=qiang.zhang1211@gmail.com \
--cc=rcu@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=urezki@gmail.com \
--cc=vbabka@suse.cz \
--cc=vincent.guittot@linaro.org \
--cc=will@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