public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Chen Yu <yu.c.chen@intel.com>
To: Hillf Danton <hdanton@sina.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Mel Gorman <mgorman@suse.de>,
	K Prateek Nayak <kprateek.nayak@amd.com>,
	Chen Yu <yu.chen.surf@gmail.com>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 3/3] sched/fair: do not scribble cache-hot CPU in select_idle_cpu()
Date: Mon, 19 Feb 2024 22:24:39 +0800	[thread overview]
Message-ID: <ZdNkp5DP8aKnsYGt@chenyu5-mobl2> (raw)
In-Reply-To: <20240219115014.1333-1-hdanton@sina.com>

Hi Hillf,

On 2024-02-19 at 19:50:14 +0800, Hillf Danton wrote:
> On Tue, 21 Nov 2023 15:40:14 +0800 Chen Yu <yu.c.chen@intel.com>
> > Problem statement:
> > When task p is woken up, the scheduler leverages select_idle_sibling()
> > to find an idle CPU for it. p's previous CPU is usually a preference
> > because it can improve cache locality. However in many cases, the
> > previous CPU has already been taken by other wakees, thus p has to
> > find another idle CPU.
> > 
> > Proposal:
> > Introduce the SIS_CACHE. It considers the sleep time of the task for
> > better task placement. Based on the task's short sleeping history,
> > tag p's previous CPU as cache-hot. Later when p is woken up, it can
> > choose its previous CPU in select_idle_sibling(). When other task is
> > woken up, skip this cache-hot idle CPU when possible.
> > 
> > SIS_CACHE still prefers to choose an idle CPU during task wakeup,
> > the idea is to optimize the idle CPU scan sequence.
> 
> Could you specify why the currently selected cpu fails to work in the
> scenario described above?
>

Thank you for your review.

I assume that "currently select cpu" means "target". First, the "target"
could be chosen by wake_affine() -> wake_affine_weight(), which can
return non-idle candidate CPU. That is to say, when we reached below code,
the target and the prev could both be non-idle. Second, when target and
prev are both non-idle, select_idle_sibling() has to traverse the other CPUs
to find an idle one. What we do in SIS_CACHE is to increase the possibility
that the prev is idle and return directly in below code path.

Say, task p1's previous CPU is CPU1, and p1 is sleeping. With SIS_CACHE,
when another task p2 is woken up in select_idle_sibling()->select_idle_cpu(),
p2 tries to find CPU2 or CPU3 or CPU4... but not CPU1. This makes it easier
for p1 to find that CPU1 is idle when p1 is woken up, and choose CPU1 when
possible.

thanks,
Chenyu
> 	/*
> 	 * If the previous CPU is cache affine and idle, don't be stupid:
> 	 */
> 	if (prev != target && cpus_share_cache(prev, target) &&
> 	    (available_idle_cpu(prev) || sched_idle_cpu(prev)) &&
> 	    asym_fits_cpu(task_util, util_min, util_max, prev))
> 		return prev;

  reply	other threads:[~2024-02-19 14:24 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-21  7:39 [PATCH v2 0/3] Introduce SIS_CACHE to choose previous CPU during task wakeup Chen Yu
2023-11-21  7:39 ` [PATCH v2 1/3] sched/fair: Record the task sleeping time as the cache hot duration Chen Yu
2023-11-21  7:39 ` [PATCH v2 2/3] sched/fair: Calculate the cache-hot time of the idle CPU Chen Yu
2023-11-21  7:40 ` [PATCH v2 3/3] sched/fair: do not scribble cache-hot CPU in select_idle_cpu() Chen Yu
2023-11-29 17:26   ` Madadi Vineeth Reddy
2023-11-30  6:43     ` Chen Yu
2023-12-01 13:56       ` Madadi Vineeth Reddy
2024-02-19 11:50   ` Hillf Danton
2024-02-19 14:24     ` Chen Yu [this message]
2023-11-25  7:10 ` [PATCH v2 2/3] sched/fair: Calculate the cache-hot time of the idle CPU Madadi Vineeth Reddy
2023-11-26  7:21   ` Chen Yu
2023-11-26  8:44 ` [PATCH v2 0/3] Introduce SIS_CACHE to choose previous CPU during task wakeup Madadi Vineeth Reddy
2023-11-26  9:25   ` Chen Yu
2024-02-18  9:27 ` Madadi Vineeth Reddy
2024-02-18 13:01   ` Chen Yu

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=ZdNkp5DP8aKnsYGt@chenyu5-mobl2 \
    --to=yu.c.chen@intel.com \
    --cc=hdanton@sina.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mgorman@suse.de \
    --cc=peterz@infradead.org \
    --cc=vincent.guittot@linaro.org \
    --cc=yu.chen.surf@gmail.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