From: Andrea Righi <arighi@nvidia.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Tejun Heo <tj@kernel.org>, Joel Fernandes <joelagnelf@nvidia.com>,
linux-kernel@vger.kernel.org, David Vernet <void@manifault.com>,
Changwoo Min <changwoo@igalia.com>,
Ingo Molnar <mingo@redhat.com>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>
Subject: Re: [PATCH RFC] sched_ext: Choose prev_cpu if idle and cache affine without WF_SYNC
Date: Tue, 18 Mar 2025 06:17:01 +0100 [thread overview]
Message-ID: <Z9kBzeGAnxtQIvi6@gpd3> (raw)
In-Reply-To: <20250317174431.GI6888@noisy.programming.kicks-ass.net>
On Mon, Mar 17, 2025 at 06:44:31PM +0100, Peter Zijlstra wrote:
> On Mon, Mar 17, 2025 at 06:30:57PM +0100, Andrea Righi wrote:
>
> > I guess the question is: what is more expensive in general on task wakeup?
> > 1) a cross-node migration or 2) running on a partially busy SMT core?
>
> That totally depends on both the workload and the actual machine :/
>
> If you have 'fast' numa and not a very big footprint, the numa
> migrations aren't too bad. OTOH if you have sucky numa or your memory
> footprint is significant, then running on the wrong node is super
> painful.
Right, there isn't a single "best solution" in general, I guess we just
need to pick what we think it works best in most cases, set that as
default, and then leave it to the BPF schedulers to adjust the behavior as
needed (at the end this is just a default policy).
Thanks,
-Andrea
next prev parent reply other threads:[~2025-03-18 5:17 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-17 8:28 [PATCH RFC] sched_ext: Choose prev_cpu if idle and cache affine without WF_SYNC Joel Fernandes
2025-03-17 17:08 ` Tejun Heo
2025-03-17 17:30 ` Andrea Righi
2025-03-17 17:44 ` Peter Zijlstra
2025-03-18 5:17 ` Andrea Righi [this message]
2025-03-17 22:11 ` Joel Fernandes
2025-03-18 5:09 ` Andrea Righi
2025-03-18 17:00 ` Joel Fernandes
2025-03-18 17:46 ` Andrea Righi
2025-03-18 22:37 ` Joel Fernandes
2025-03-17 22:07 ` Joel Fernandes
2025-03-17 22:25 ` Tejun Heo
2025-03-17 22:45 ` Joel Fernandes
2025-03-18 0:12 ` Libo Chen
2025-03-18 0:14 ` Tejun Heo
2025-03-17 17:20 ` Andrea Righi
2025-03-17 22:44 ` Joel Fernandes
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=Z9kBzeGAnxtQIvi6@gpd3 \
--to=arighi@nvidia.com \
--cc=bsegall@google.com \
--cc=changwoo@igalia.com \
--cc=dietmar.eggemann@arm.com \
--cc=joelagnelf@nvidia.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tj@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=void@manifault.com \
--cc=vschneid@redhat.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