From: Peter Zijlstra <peterz@infradead.org>
To: Tim Chen <tim.c.chen@linux.intel.com>
Cc: 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>,
K Prateek Nayak <kprateek.nayak@amd.com>,
Kees Cook <kees@kernel.org>,
Christian Brauner <brauner@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>,
Shrikanth Hegde <sshegde@linux.ibm.com>,
Qais Yousef <qyousef@layalina.io>,
Aaron Lu <ziqianlu@bytedance.com>,
Srikar Dronamraju <srikar@linux.ibm.com>,
Vineeth Remanan Pillai <vineethr@linux.ibm.com>,
Ricardo Neri-Calderon <ricardo.neri-calderon@linux.intel.com>,
Chen Yu <yu.c.chen@intel.com>, Lu Wang <wanglu.priv@gmail.com>,
Hyunwoo Kim <imv4bel@gmail.com>,
Zhan Xusheng <zhanxusheng@xiaomi.com>,
Zhan Xusheng <zhanxusheng1024@gmail.com>,
Yi Lai <yi1.lai@intel.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 3/4] sched/cache: Decouple sched_cache_group from mm
Date: Wed, 16 Sep 2026 14:54:40 +0200 [thread overview]
Message-ID: <20260916125440.GF776954@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <cb678eddae708e2865ec69a04edf999119c2168a.1789061845.git.tim.c.chen@linux.intel.com>
On Thu, Sep 10, 2026 at 10:46:11AM -0700, Tim Chen wrote:
> +static void sched_cache_group_free_rcu(struct rcu_head *rcu)
> +{
> + struct sched_cache_group *grp =
> + container_of(rcu, struct sched_cache_group, rcu);
> +
> + /* free_percpu() may be called from atomic context. */
That comment is misleading at best. This is rcu-free context. And
free_percpu() is not allowed from actual atomic context on RT.
> + free_percpu(grp->pcpu_sched);
> + kfree(grp);
> +}
> +
> +void sched_cache_group_put(struct sched_cache_group *grp)
> +{
> + if (!grp || !refcount_dec_and_test(&grp->refcnt))
> + return;
> +
> + call_rcu(&grp->rcu, sched_cache_group_free_rcu);
> +}
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 32213801ea39..b5a823f0a622 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -1669,18 +1677,35 @@ void mm_init_sched(struct mm_struct *mm,
> epoch = rq->cpu_epoch;
> }
>
> - raw_spin_lock_init(&mm->sc_stat.lock);
> - mm->sc_stat.epoch = epoch;
> - mm->sc_stat.cpu = -1;
> - mm->sc_stat.next_scan = jiffies;
> - mm->sc_stat.nr_running_avg = 0;
> - mm->sc_stat.footprint = 0;
> + raw_spin_lock_init(&grp->lock);
> + grp->epoch = epoch;
> + grp->cpu = -1;
> + grp->next_scan = jiffies;
> + grp->nr_running_avg = 0;
> + grp->footprint = 0;
> + refcount_set(&grp->refcnt, 1);
> /*
> - * The update to mm->sc_stat should not be reordered
> - * before initialization to mm's other fields, in case
> + * The update to grp->pcpu_sched should not be reordered
> + * before initialization to grp's other fields, in case
> * the readers may get invalid mm_sched_epoch, etc.
> */
> - smp_store_release(&mm->sc_stat.pcpu_sched, _pcpu_sched);
> + smp_store_release(&grp->pcpu_sched, _pcpu_sched);
> + /*
> + * Publish the group last. Not every reader qualifies it by
> + * grp->pcpu_sched - can_migrate_llc_task() only checks that the
> + * pointer is non-NULL before reading grp->footprint and
> + * grp->nr_running_avg - so a reachable group must already be
> + * fully initialized.
> + */
> + mm->sched_cache_grp = grp;
If it is a publish it needs to be store-release.
> + return 0;
> +}
> +
> +void mm_destroy_sched(struct mm_struct *mm)
> +{
> + if (mm->sched_cache_grp)
> + sched_cache_group_put(mm->sched_cache_grp);
> + mm->sched_cache_grp = NULL;
> }
>
> /* because why would C be fully specified */
> @@ -1738,7 +1763,7 @@ static int get_pref_llc(struct task_struct *p, struct mm_struct *mm)
> if (!mm)
> return -1;
>
> - mm_sched_cpu = READ_ONCE(mm->sc_stat.cpu);
> + mm_sched_cpu = READ_ONCE(mm->sched_cache_grp->cpu);
> if (mm_sched_cpu != -1) {
> mm_sched_llc = llc_id(mm_sched_cpu);
>
> @@ -1781,11 +1806,15 @@ void account_mm_sched(struct rq *rq, struct task_struct *p, s64 delta_exec)
> /*
> * init_task, kthreads and user thread created
> * by user_mode_thread() don't have mm.
> + *
> + * A kthread can temporarily adopt an mm via kthread_use_mm(),
> + * so p->mm alone does not imply a user task.
This seems like a related but distinct fix, no?
> */
> - if (!mm || !mm->sc_stat.pcpu_sched)
> + if (!mm || p->flags & PF_KTHREAD || !mm->sched_cache_grp ||
> + !mm->sched_cache_grp->pcpu_sched)
> return;
Is this susceptible to TOCTOU ?
>
> - pcpu_sched = per_cpu_ptr(mm->sc_stat.pcpu_sched, cpu_of(rq));
> + pcpu_sched = per_cpu_ptr(mm->sched_cache_grp->pcpu_sched, cpu_of(rq));
>
> scoped_guard (raw_spinlock, &rq->cpu_epoch_lock) {
> __update_mm_sched(rq, pcpu_sched);
> @@ -1798,11 +1827,11 @@ void account_mm_sched(struct rq *rq, struct task_struct *p, s64 delta_exec)
> * If this process hasn't hit task_cache_work() for a while invalidate
> * its preferred state.
> */
> - if ((long)(epoch - READ_ONCE(mm->sc_stat.epoch)) > llc_epoch_affinity_timeout ||
> + if ((long)(epoch - READ_ONCE(mm->sched_cache_grp->epoch)) > llc_epoch_affinity_timeout ||
> invalid_llc_nr(mm, p, cpu_of(rq)) ||
> exceed_llc_capacity(mm, cpu_of(rq))) {
> - if (READ_ONCE(mm->sc_stat.cpu) != -1)
> - WRITE_ONCE(mm->sc_stat.cpu, -1);
> + if (READ_ONCE(mm->sched_cache_grp->cpu) != -1)
> + WRITE_ONCE(mm->sched_cache_grp->cpu, -1);
> }
>
> mm_sched_llc = get_pref_llc(p, mm);
Perhaps it makes sense to have a local:
struct sched_cache_group *scg = READ_ONCE(mm->sched_cache_grp);
because as is, the compiler is free to keep re-loading that. I mean,
dumb, but allowed. Also the local variable will shorten some of those
long expressions.
Somewhat applicable to the rest of the patch too, where it makes sense
and all that.
next prev parent reply other threads:[~2026-09-16 12:55 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 17:46 [PATCH 0/4] sched/cache: Fixes for cache aware scheduling Tim Chen
2026-09-10 17:46 ` [PATCH 1/4] sched/cache: Keep nr_pref_llc_running in the runnable domain Tim Chen
2026-09-10 18:33 ` Kayra Cizmeci
2026-09-10 20:46 ` Tim Chen
2026-09-10 22:03 ` Kayra Cizmeci
2026-09-14 2:02 ` Chen Yu
2026-09-14 5:27 ` Kayra Cizmeci
2026-09-14 22:25 ` Tim Chen
2026-09-10 22:48 ` Kayra Cizmeci
2026-09-16 12:30 ` Peter Zijlstra
2026-09-16 13:33 ` Kayra Cizmeci
2026-09-10 17:46 ` [PATCH 2/4] sched/cache: Honor migrate_llc_task semantics in active load balance Tim Chen
2026-09-10 17:46 ` [PATCH 3/4] sched/cache: Decouple sched_cache_group from mm Tim Chen
2026-09-16 12:54 ` Peter Zijlstra [this message]
2026-09-10 17:46 ` [PATCH 4/4] sched/cache: Introduce task_struct->sched_cache_grp Tim Chen
2026-09-10 19:19 ` Peter Zijlstra
2026-09-10 22:50 ` Tim Chen
2026-09-14 14:34 ` Chen Yu
2026-09-16 13:02 ` Peter Zijlstra
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=20260916125440.GF776954@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=brauner@kernel.org \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=imv4bel@gmail.com \
--cc=jack@suse.cz \
--cc=juri.lelli@redhat.com \
--cc=kees@kernel.org \
--cc=kprateek.nayak@amd.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=qyousef@layalina.io \
--cc=ricardo.neri-calderon@linux.intel.com \
--cc=rostedt@goodmis.org \
--cc=srikar@linux.ibm.com \
--cc=sshegde@linux.ibm.com \
--cc=tim.c.chen@linux.intel.com \
--cc=vincent.guittot@linaro.org \
--cc=vineethr@linux.ibm.com \
--cc=viro@zeniv.linux.org.uk \
--cc=vschneid@redhat.com \
--cc=wanglu.priv@gmail.com \
--cc=yi1.lai@intel.com \
--cc=yu.c.chen@intel.com \
--cc=zhanxusheng1024@gmail.com \
--cc=zhanxusheng@xiaomi.com \
--cc=ziqianlu@bytedance.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
all inboxes | Powered by JetHome®