All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Righi <arighi@nvidia.com>
To: Tejun Heo <tj@kernel.org>
Cc: David Vernet <void@manifault.com>,
	Changwoo Min <changwoo@igalia.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	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>,
	K Prateek Nayak <kprateek.nayak@amd.com>,
	Vladimir Vdovin <deliran@verdict.gg>,
	Emil Tsalapatis <etsal@meta.com>,
	Christian Loehle <christian.loehle@arm.com>,
	Balbir Singh <balbirs@nvidia.com>,
	Lee Trager <ltrager@nvidia.com>,
	sched-ext@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCHSET sched_ext/for-7.4] sched_ext: Add NUMA balancing support
Date: Fri, 9 Oct 2026 23:03:42 +0200	[thread overview]
Message-ID: <aslWrnlHYy9b5lEm@gpd4> (raw)
In-Reply-To: <61b9a8607e1f25ffd316f13135432581@kernel.org>

Hi Tejun,

On Thu, Oct 08, 2026 at 08:23:16AM -1000, Tejun Heo wrote:
> Hello, Andrea.
> 
> On Sun, Oct 04, 2026 at 09:27:06AM +0200, Andrea Righi wrote:
> > This series lets a BPF scheduler opt into the NUMA hinting-fault scan with
> > SCX_OPS_NUMA_BALANCING. The existing scan is driven from the sched_ext tick for
> > the tasks of such a scheduler, and the hinting faults then work for them as they
> > do for fair tasks: the kernel maintains their NUMA fault statistics and
> > preferred node, and migrates the memory a task accesses toward the node it runs
> > on. The tasks themselves are not migrated: their placement is left to the BPF
> > scheduler.
> >
> > The resulting preferred node is exposed to BPF schedulers with
> > scx_bpf_task_numa_nid(), which they can use to keep a task close to its memory
> > when placing or balancing it. The value is advisory; nothing in the kernel acts
> > on it for these tasks.
> 
> Is there a reason to gate this on a separate ops flag? An alternative would be
> an op which is called when a task's preferred node changes, with the initial
> node reported on enable like ops.set_weight(), and enabling the hinting-fault
> scan iff the op is implemented. The scheduler then gets an event it can act on
> rather than a value to poll. The node has a single writer, sched_setnuma(),
> which already dequeues and re-enqueues the task under the rq lock, so the op
> can be called from there the same way ops.set_weight() is called from the
> reweight path.

Yeah, there's no particular reason to use a separate ops flag. I think I like
the ops callback approach that reports the preferred node and enables the
hinting-fault scan when the callback is implemented. Maybe something like:

  void (*set_numa_node)(struct task_struct *p, s32 nid);

Calling it from sched_setnuma() under the rq lock should also simplify the code
and lets the BPF scheduler update its placement state before the task is
re-enqueued.

I'll do some experiments with this approach and send a new version.

Thanks,
-Andrea

      reply	other threads:[~2026-10-09 21:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-04  7:27 [PATCHSET sched_ext/for-7.4] sched_ext: Add NUMA balancing support Andrea Righi
2026-10-04  7:27 ` [PATCH 1/5] sched/numa: Let other scheduling classes drive NUMA scanning Andrea Righi
2026-10-04  7:27 ` [PATCH 2/5] sched/numa: Leave the placement of a BPF-scheduled task to its scheduler Andrea Righi
2026-10-04  7:27 ` [PATCH 3/5] sched_ext: Scan NUMA hinting faults for opted-in BPF schedulers Andrea Righi
2026-10-05 11:30   ` Vladimir Vdovin
2026-10-05 21:37     ` Andrea Righi
2026-10-04  7:27 ` [PATCH 4/5] sched_ext: Add scx_bpf_task_numa_nid() Andrea Righi
2026-10-04  7:27 ` [PATCH 5/5] selftests/sched_ext: Add a test for scx_bpf_task_numa_nid() Andrea Righi
2026-10-06 14:40 ` [PATCHSET sched_ext/for-7.4] sched_ext: Add NUMA balancing support Vladimir Vdovin
2026-10-08 18:23 ` Tejun Heo
2026-10-09 21:03   ` Andrea Righi [this message]

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=aslWrnlHYy9b5lEm@gpd4 \
    --to=arighi@nvidia.com \
    --cc=balbirs@nvidia.com \
    --cc=bsegall@google.com \
    --cc=changwoo@igalia.com \
    --cc=christian.loehle@arm.com \
    --cc=deliran@verdict.gg \
    --cc=dietmar.eggemann@arm.com \
    --cc=etsal@meta.com \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ltrager@nvidia.com \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sched-ext@lists.linux.dev \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.