From: Tim Chen <tim.c.chen@linux.intel.com>
To: Luo Gengkun <luogengkun2@huawei.com>,
peterz@infradead.org, mingo@redhat.com, juri.lelli@redhat.com,
vincent.guittot@linaro.org, yu.c.chen@intel.com
Cc: dietmar.eggemann@arm.com, rostedt@goodmis.org,
bsegall@google.com, mgorman@suse.de, vschneid@redhat.com,
kprateek.nayak@amd.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 linux 1/2] sched/cache: Reduce the overhead of task_cache_work by only scan the visisted cpus
Date: Tue, 21 Jul 2026 07:59:12 -0700 [thread overview]
Message-ID: <a9c831e7304c70ec6bcdba7045769b30d3193245.camel@linux.intel.com> (raw)
In-Reply-To: <d91a1f3a-1164-4d55-90ba-cd4188190d1b@huawei.com>
On Tue, 2026-07-21 at 10:53 +0800, Luo Gengkun wrote:
>
>
snip
> > > -static unsigned long fraction_mm_sched(struct rq *rq,
> > > - struct sched_cache_time *pcpu_sched)
> > > +static unsigned long fraction_mm_sched(int cpu,
> > > + struct mm_struct *mm)
> > > {
> > > + struct sched_cache_time *pcpu_sched =
> > > + per_cpu_ptr(mm->sc_stat.pcpu_sched, cpu);
> > > + struct rq *rq = cpu_rq(cpu);
> > > +
> > > guard(raw_spinlock_irqsave)(&rq->cpu_epoch_lock);
> > >
> > > __update_mm_sched(rq, pcpu_sched);
> > >
> > > + /* Skip the rq that has not been hit for a long time */
> > > + if ((rq->cpu_epoch - pcpu_sched->epoch_last_visit) > llc_epoch_affinity_timeout) {
> > > + cpumask_clear_cpu(cpu, mm->sc_stat.visited_cpus);
> > > + return 0;
> > > + }
> > > +
> > > /*
> > > * Runtime is a geometric series (r=0.5) and as such will sum to twice
> > > * the accumulation period, this means the multiplcation here should
> > > @@ -1711,6 +1722,9 @@ void account_mm_sched(struct rq *rq, struct task_struct *p, s64 delta_exec)
> > > pcpu_sched->runtime += delta_exec;
> > > rq->cpu_runtime += delta_exec;
> > > epoch = rq->cpu_epoch;
> > > + pcpu_sched->epoch_last_visit = epoch;
> >
> > We need to make sure that the epoch_last_visit update is seen by the cpu
> > running task_cache_work(), before it attempts to do the epoch comparison
> > and clear the cpu, and causing inconsistency in the visited_cpus.
> >
> > For example
> >
> > CPU A (e.g. doing LLC/affinity selection, reading remote pcpu_sched) CPU B (= `cpu`, running account_mm_sched() locally)
> > -------------------------------------------------------------------- -----------------------------------------------------
> > read pcpu_sched->epoch_last_visit (stale, old value)
> > -> looks like it timed out
> > pcpu_sched->epoch_last_visit = epoch (fresh visit!)
> > cpumask_set_cpu(cpu, visited_cpus) (correctly marks it visited)
> > cpumask_clear_cpu(cpu, visited_cpus) <-- wipes out the fresh set!
> >
> I don't think such a race condition will occur, because both the read and clear
> operations in fraction_mm_sched() are protected by rq->cpu_epoch_lock, just like
> account_mm_sched(). Please let me know if I'm missing something.
>
Yes, the epoch lock should prevent the above race from happening.
Missed that on my end.
>
Thanks.
Tim
next prev parent reply other threads:[~2026-07-21 14:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 12:22 [PATCH v7 linux 0/2] Cache aware scheduling: Reduce the overhead of task_cache_work Luo Gengkun
2026-07-20 12:22 ` [PATCH v7 linux 1/2] sched/cache: Reduce the overhead of task_cache_work by only scan the visisted cpus Luo Gengkun
2026-07-20 22:09 ` Tim Chen
2026-07-21 2:53 ` Luo Gengkun
2026-07-21 14:59 ` Tim Chen [this message]
2026-07-20 12:22 ` [PATCH v7 linux 2/2] -- DO NOT APPLY!!! -- sched/cache/debug: Add trace event and sched feature to track scan cost Luo Gengkun
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=a9c831e7304c70ec6bcdba7045769b30d3193245.camel@linux.intel.com \
--to=tim.c.chen@linux.intel.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luogengkun2@huawei.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=yu.c.chen@intel.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®