mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Chen, Yu C" <yu.c.chen@intel.com>
To: Luo Gengkun <luogengkun2@huawei.com>
Cc: <dietmar.eggemann@arm.com>, <rostedt@goodmis.org>,
	<bsegall@google.com>, <mgorman@suse.de>, <peterz@infradead.org>,
	<vschneid@redhat.com>, <kprateek.nayak@amd.com>,
	<linux-kernel@vger.kernel.org>, <juri.lelli@redhat.com>,
	<mingo@redhat.com>, <vincent.guittot@linaro.org>,
	<tim.c.chen@linux.intel.com>,
	"chen.yu@linux.dev" <chen.yu@linux.dev>
Subject: Re: [PATCH v5 1/2] sched/cache: Reduce the overhead of task_cache_work by only scan the visisted cpus
Date: Thu, 9 Jul 2026 23:01:16 +0800	[thread overview]
Message-ID: <d2a0a72f-65d1-40c2-ac84-f296094d2e9f@intel.com> (raw)
In-Reply-To: <20260709130053.2749834-2-luogengkun2@huawei.com>

Hi Gengkun,

thanks for the update,

On 7/9/2026 9:00 PM, Luo Gengkun wrote:

> +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);
>   
> +	/* Skip the rq that has not been hit for a long time */
> +	if ((rq->cpu_epoch - pcpu_sched->epoch_timeout) > llc_epoch_affinity_timeout) {
> +		cpumask_clear_cpu(cpu, &mm->sc_stat.visited_cpus);
> +		return 0;
> +	}
> +

I was wondering if there is a race condition in the scenario
above: If the rq has just updated its cpu_epoch field, and the
CPU subsequently remains idle, then rq->cpu_epoch stays unchanged.
That is to say, a race could occur as follows: if CPU1 becomes idle,
CPU2's task_cache_work() might compute
rq->cpu_epoch - pcpu_sched->epoch_timeout == 0 and consequently fail
to clear CPU1 from visit_cpus.

CPU_1                                     CPU_2
------------------------------------      ---------------------------------
account_mm_sched(rq_X)
   set CPU1 in visited_cpus


(idle: fair task runs here,
  CPU1.cpu_epoch frozen afterwards,
  pcpu_sched->epoch_timeout = CPU1.epoch)
                                           fraction_mm_sched()
                                             CPU1->cpu_epoch - 
pcpu_sched->epoch_timeout = 0
                                             -> bit CPU1 not cleared
                                             __update_mm_sched() 
->update cpu_epoch, too late
I wonder if we should let __update_mm_sched() be invoked before
if ((rq->cpu_epoch - pcpu_sched->epoch_timeout) > 
llc_epoch_affinity_timeout)?

BTW, in your test data:
sched_cache_scan: comm=redis-server pid=24660 scan=384
Is it because NUMA balancing is disabled on your platform that it has
to scan all the CPUs? It would be helpful to know what the result would
be with NUMA balancing enabled.
I found some reports from sashiko here that are worth taking a look at:
https://sashiko.dev/#/patchset/20260709130053.2749834-1-luogengkun2%40huawei.com

thanks,
Chenyu


  reply	other threads:[~2026-07-09 15:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-09 13:00 [PATCH v5 linux 0/2] Cache aware scheduling: Reduce the overhead of task_cache_work Luo Gengkun
2026-07-09 13:00 ` [PATCH v5 1/2] sched/cache: Reduce the overhead of task_cache_work by only scan the visisted cpus Luo Gengkun
2026-07-09 15:01   ` Chen, Yu C [this message]
2026-07-14  2:22     ` Luo Gengkun
2026-07-14 22:40     ` Tim Chen
2026-07-15  6:41       ` Luo Gengkun
2026-07-15 20:44         ` Tim Chen
2026-07-09 13:00 ` [PATCH v5 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=d2a0a72f-65d1-40c2-ac84-f296094d2e9f@intel.com \
    --to=yu.c.chen@intel.com \
    --cc=bsegall@google.com \
    --cc=chen.yu@linux.dev \
    --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=tim.c.chen@linux.intel.com \
    --cc=vincent.guittot@linaro.org \
    --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

all inboxes | Powered by JetHome®