public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tim Chen <tim.c.chen@linux.intel.com>
To: "Chen, Yu C" <yu.c.chen@intel.com>,
	Madadi Vineeth Reddy <vineethr@linux.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	K Prateek Nayak <kprateek.nayak@amd.com>,
	"Gautham R . Shenoy" <gautham.shenoy@amd.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	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>,
	Tim Chen <tim.c.chen@intel.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Libo Chen <libo.chen@oracle.com>,
	Abel Wu <wuyun.abel@bytedance.com>,
	Hillf Danton <hdanton@sina.com>,
	 linux-kernel@vger.kernel.org, Len Brown <len.brown@intel.com>,
	Chen Yu <yu.chen.surf@foxmail.com>
Subject: Re: [RFC PATCH 4/5] sched: Inhibit cache aware scheduling if the preferred LLC is over aggregated
Date: Thu, 24 Apr 2025 08:51:50 -0700	[thread overview]
Message-ID: <e45141a1a64d7dcfca2683f56735ba4da60ba19e.camel@linux.intel.com> (raw)
In-Reply-To: <d221a260-51d5-4dec-8c08-37d27dd80145@intel.com>

On Thu, 2025-04-24 at 22:11 +0800, Chen, Yu C wrote:
> 
> > It spawns lot of threads and is CPU intensive. So, I think it's not impacted
> > due to the below conditions.
> > 
> > Also, in schbench numbers provided by you, there is a degradation in saturated
> > case. Is it due to the overhead in computing the preferred llc which is not
> > being used due to below conditions?
> 
> Yes, the overhead of preferred LLC calculation could be one part, and we 
> also suspect that the degradation might be tied to the task migrations. 
> We still observed more task migrations than the baseline, even when the 
> system was saturated (in theory, after 25% is exceeded, we should 
> fallback to the generic task wakeup path). We haven't dug into that yet, 
> and we can conduct an investigation in the following days.

In the saturation case it is mostly the tail latency that has regression.
The preferred LLC has a tendency to have higher load than the
other LLCs. Load balancer will try to move tasks out and wake balance will
try to move it back to the preferred LLC. This increases the task migrations
and affect tail latency.

Tim

  reply	other threads:[~2025-04-24 15:51 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-21  3:23 [RFC PATCH 0/5] sched: Introduce Cache aware scheduling Chen Yu
2025-04-21  3:24 ` [RFC PATCH 1/5] sched: Cache aware load-balancing Chen Yu
2025-04-21  3:24 ` [RFC PATCH 2/5] sched: Several fixes for cache aware scheduling Chen Yu
2025-04-21  3:25 ` [RFC PATCH 3/5] sched: Avoid task migration within its preferred LLC Chen Yu
2025-04-21  3:25 ` [RFC PATCH 4/5] sched: Inhibit cache aware scheduling if the preferred LLC is over aggregated Chen Yu
2025-04-24  9:22   ` Madadi Vineeth Reddy
2025-04-24 14:11     ` Chen, Yu C
2025-04-24 15:51       ` Tim Chen [this message]
2025-04-25  9:13         ` Madadi Vineeth Reddy
2025-04-25 17:29           ` Tim Chen
2025-04-25  8:58       ` Madadi Vineeth Reddy
2025-04-21  3:25 ` [RFC PATCH 5/5] sched: Add ftrace to track task migration and load balance within and across LLC Chen Yu
2025-04-29  3:47 ` [RFC PATCH 0/5] sched: Introduce Cache aware scheduling K Prateek Nayak
2025-04-29 12:57   ` Chen, Yu C

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=e45141a1a64d7dcfca2683f56735ba4da60ba19e.camel@linux.intel.com \
    --to=tim.c.chen@linux.intel.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=gautham.shenoy@amd.com \
    --cc=hdanton@sina.com \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=len.brown@intel.com \
    --cc=libo.chen@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tim.c.chen@intel.com \
    --cc=vincent.guittot@linaro.org \
    --cc=vineethr@linux.ibm.com \
    --cc=vschneid@redhat.com \
    --cc=wuyun.abel@bytedance.com \
    --cc=yu.c.chen@intel.com \
    --cc=yu.chen.surf@foxmail.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