Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1;
Date:   Wed, 20 Sep 2023 20:34:49 +0800
From:   Chen Yu <yu.c.chen@intel.com>
To:     Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
CC:     Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Juri Lelli <juri.lelli@redhat.com>,
        Tim Chen <tim.c.chen@intel.com>, Aaron Lu <aaron.lu@intel.com>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        "Steven Rostedt" <rostedt@goodmis.org>,
        Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
        Daniel Bristot de Oliveira <bristot@redhat.com>,
        "Valentin Schneider" <vschneid@redhat.com>,
        K Prateek Nayak <kprateek.nayak@amd.com>,
        "Gautham R . Shenoy" <gautham.shenoy@amd.com>,
        <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 2/2] sched/fair: skip the cache hot CPU in
 select_idle_cpu()
Message-ID: <ZQrm6e9apSMwDh5E@chenyu5-mobl2.ccr.corp.intel.com>
References: <cover.1694397335.git.yu.c.chen@intel.com>
 <d49cf5748aa7c6d69580315d2373a9eafa21c21f.1694397335.git.yu.c.chen@intel.com>
 <30a7ff14-3f48-e8cf-333f-cbb7499656e3@efficios.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <30a7ff14-3f48-e8cf-333f-cbb7499656e3@efficios.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?meHuRvI8hRGHl78jLH82F1wAVL9DV8nxs06Yb830/Hnj2ZQ9e+wHDQGHrLb+?=
 =?us-ascii?Q?gbIbs96A4z6veRG4jXVHZTRmcfsweO/0YtoTak7AdjEnIU3C0fRgiuIYv8Vl?=
 =?us-ascii?Q?8qig2wz5gL4gGEQPfUOm9gFyOYO1ytrTmDP5nbc6yGZE+7G9hkeFGO4ZfjA6?=
 =?us-ascii?Q?ijPBrnK6VnF3MqUAF7/yzsQW/sIEkm9G91jZWHZqeH93lAI84SQrFdpvvoOE?=
 =?us-ascii?Q?4tKdaM3jwuiSMxMYqqsb4R8giXOyBgEna/xNGmEhKHjGq/bDZIWUZWx//1q5?=
 =?us-ascii?Q?bi7PdYNp8IV297go5FIXDuix1iynoxoLhCTk25cKtTOXOQKNnlIt/iwK15Cp?=
 =?us-ascii?Q?vB8a5eaxDYrxTaFid86LxmB2cgYwaI1ruPNgzqklKaCgSNmEmJnyP2zt1c8H?=
 =?us-ascii?Q?ystzOvagLI2BhAkzmIgGFAyRfxuc905piifzs5AOA3wkCCmSe7hWmH2eQTcY?=
 =?us-ascii?Q?i8IYh/+3vibsC17kkmRYK+C42rWEOAH/treaSumzJuQtFbeIoisaEVIrgeZ5?=
 =?us-ascii?Q?zVOsvCCJ9tg18udeQnpTwaD3IZizWleT85zJ+9ZEDwcHHvekVWHHTR15PV6F?=
 =?us-ascii?Q?VbRb6DQn/Z6eEs20gPRAlUn/DlFfymmNVtAmyZ+ghhMPfx8VczC9SSsMaOlw?=
 =?us-ascii?Q?opaiEZy4GvEGE9Gpq4xYo6hMShASvx7kAelN4Q/WcQYV6Ru4Zb9z2kD8aouz?=
 =?us-ascii?Q?Et8JRST+LKT5nxFBOLeJ7uqRcYbtS3vwtynlIX9KGYnQW2wM72W3cjYBkddy?=
 =?us-ascii?Q?ZO92MpzpzCsB0zUZSc/NxbnzjuqoZVcO9oNnB7PBjQxicH4thl2p8Ul30dD9?=
 =?us-ascii?Q?ZEX/VecdyVnxyH6+x5vtyXVle9iDzH4l+EGgBU2Gj3IYAtyC6CT0tYpNSK9H?=
 =?us-ascii?Q?LYrLjpc43S/kjBjf+pt9XX0zMvMVf2bYwl77BV4+P9CUyfPK0l8WwPyJow9T?=
 =?us-ascii?Q?qxPGSkKM6+rJyZncHOEFc8gbJyriqdTrm6CDWngdwX5aQRd8mztUy42hIbTm?=
 =?us-ascii?Q?eX4jNErFSi5Nwg7ebfcM69DUwFvp6XJsullgIyQTK9skTiifiYLVU4yfu8e2?=
 =?us-ascii?Q?Fe4vxg9EzK8RJuUeQbdZkA8DSTG1vSvStXgwgmRJ/VW5cMz6H5W0DHnXrnf+?=
 =?us-ascii?Q?FWsgCk/OS4EUDKl96x07zn4twu1AFggauvW4hN8YwnpC3zwu1u8+Gcii83fM?=
 =?us-ascii?Q?3ndYLBXWdD5NAaddF0POrqOg110mXpdam8HPOMlVEIuuz1K77YnVR1rGLCK4?=
 =?us-ascii?Q?7KePS7CVfqrreUC9v/qPYVZ1ViKqg25w1jtzL96gxnnZw3XTObMNiynAqKIg?=
 =?us-ascii?Q?/t+MpKSH8cD49YqkmawMbhipYTkGFL64VzLBGFnZ1IEaluSfKFTLbT0J8MKs?=
 =?us-ascii?Q?jo3rVP9e8qa9tubZITa2DOqe2KuXOc3qfCDp7TzbXvYo3SrpH4/OFnXEuCYD?=
 =?us-ascii?Q?bOYgoh/gLgL2/jDJiuPDWCoKgBzX2RpSx99GflVCmYkKjq6rnNazwIYhxts+?=
 =?us-ascii?Q?4mef8f49pLitJvSl3pJ2QPMfwSlLwN3Lu8blhHX8rFPAt50xSsBF9RzCvUzz?=
 =?us-ascii?Q?kKi4tMNrgdNaXvrla1o57S737jpq7bJdN+1d12ZR?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 075fc09a-45b1-4b3a-bf2b-08dbb9d6056e
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6206.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Sep 2023 12:35:07.2306
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: RsDvq6Y1TLFAlhZr+0+QsqgMldYzoFsT8cyDNZEmhgDP/sPY/bugliXMhErEcmSjdAtDZt9KCiEkmOYwhBw6qw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR11MB6276
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable
	autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Wed, 20 Sep 2023 05:35:50 -0700 (PDT)

Hi Mathieu,

On 2023-09-11 at 11:26:50 -0400, Mathieu Desnoyers wrote:
> On 9/10/23 22:50, Chen Yu wrote:
> > 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.
> > 
> > Inspired by Mathieu's idea[1], consider the sleep time of the task.
> > If that task is a short sleeping one, keep p's previous CPU idle
> > for a short while. Later when p is woken up, it can choose its
> > previous CPU in select_idle_sibling(). When p's previous CPU is reserved,
> > other wakee is not allowed to choose this CPU in select_idle_idle().
> > The reservation period is set to the task's average sleep time. That
> > is to say, if p is a short sleeping task, there is no need to migrate
> > p to another idle CPU.
> > 
> > This does not break the work conservation of the scheduler,
> > because wakee will still try its best to find an idle CPU.
> > The difference is that, different idle CPUs might have different
> > priorities. On the other hand, in theory this extra check could
> > increase the failure ratio of select_idle_cpu(), but per the
> > initial test result, no regression is detected.
> > 
> > Baseline: tip/sched/core, on top of:
> > Commit 3f4feb58037a ("sched: Misc cleanups")
> > 
> > Benchmark results on Intel Sapphire Rapids, 112 CPUs/socket, 2 sockets.
> > cpufreq governor is performance, turbo boost is disabled, C-states deeper
> > than C1 are disabled, Numa balancing is disabled.
> > 
> > netperf
> > =======
> > case                    load            baseline(std%)  compare%( std%)
> > UDP_RR                  56-threads       1.00 (  1.34)   +1.05 (  1.04)
> > UDP_RR                  112-threads      1.00 (  7.94)   -0.68 ( 14.42)
> > UDP_RR                  168-threads      1.00 ( 33.17)  +49.63 (  5.96)
> > UDP_RR                  224-threads      1.00 ( 13.52)  +122.53 ( 18.50)
> > 
> > Noticeable improvements of netperf is observed in 168 and 224 threads
> > cases.
> > 
> > hackbench
> > =========
> > case                    load            baseline(std%)  compare%( std%)
> > process-pipe            1-groups         1.00 (  5.61)   -4.69 (  1.48)
> > process-pipe            2-groups         1.00 (  8.74)   -0.24 (  3.10)
> > process-pipe            4-groups         1.00 (  3.52)   +1.61 (  4.41)
> > process-sockets         1-groups         1.00 (  4.73)   +2.32 (  0.95)
> > process-sockets         2-groups         1.00 (  1.27)   -3.29 (  0.97)
> > process-sockets         4-groups         1.00 (  0.09)   +0.24 (  0.09)
> > threads-pipe            1-groups         1.00 ( 10.44)   -5.88 (  1.49)
> > threads-pipe            2-groups         1.00 ( 19.15)   +5.31 ( 12.90)
> > threads-pipe            4-groups         1.00 (  1.74)   -5.01 (  6.44)
> > threads-sockets         1-groups         1.00 (  1.58)   -1.79 (  0.43)
> > threads-sockets         2-groups         1.00 (  1.19)   -8.43 (  6.91)
> > threads-sockets         4-groups         1.00 (  0.10)   -0.09 (  0.07)
> > 
> > schbench(old)
> > ========
> > case                    load            baseline(std%)  compare%( std%)
> > normal                  1-mthreads       1.00 (  0.63)   +1.28 (  0.37)
> > normal                  2-mthreads       1.00 (  8.33)   +1.58 (  2.83)
> > normal                  4-mthreads       1.00 (  2.48)   -2.98 (  3.28)
> > normal                  8-mthreads       1.00 (  3.97)   +5.01 (  1.28)
> > 
> > No much difference is observed in hackbench/schbench, due to the
> > run-to-run variance.
> > 
> > Link: https://lore.kernel.org/lkml/20230905171105.1005672-2-mathieu.desnoyers@efficios.com/ #1
> > Suggested-by: Tim Chen <tim.c.chen@intel.com>
> > Signed-off-by: Chen Yu <yu.c.chen@intel.com>
> > ---
> >   kernel/sched/fair.c     | 30 +++++++++++++++++++++++++++---
> >   kernel/sched/features.h |  1 +
> >   kernel/sched/sched.h    |  1 +
> >   3 files changed, 29 insertions(+), 3 deletions(-)
> > 
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index e20f50726ab8..fe3b760c9654 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -6629,6 +6629,21 @@ static void dequeue_task_fair(struct rq *rq, struct task_struct *p, int flags)
> >   	hrtick_update(rq);
> >   	now = sched_clock_cpu(cpu_of(rq));
> >   	p->se.prev_sleep_time = task_sleep ? now : 0;
> > +#ifdef CONFIG_SMP
> > +	/*
> > +	 * If this rq will become idle, and dequeued task is
> > +	 * a short sleeping one, check if we can reserve
> > +	 * this idle CPU for that task for a short while.
> > +	 * During this reservation period, other wakees will
> > +	 * skip this 'idle' CPU in select_idle_cpu(), and this
> > +	 * short sleeping task can pick its previous CPU in
> > +	 * select_idle_sibling(), which brings better cache
> > +	 * locality.
> > +	 */
> > +	if (sched_feat(SIS_CACHE) && task_sleep && !rq->nr_running &&
> > +	    p->se.sleep_avg && p->se.sleep_avg < sysctl_sched_migration_cost)
> > +		rq->cache_hot_timeout = now + p->se.sleep_avg;
> 
> This is really cool!
> 
> There is one scenario that worries me with this approach: workloads
> that sleep for a long time and then have short blocked periods.
> Those bursts will likely bring the average to values too high
> to stay below sysctl_sched_migration_cost.
> 
> I wonder if changing the code above for the following would help ?
> 
> if (sched_feat(SIS_CACHE) && task_sleep && !rq->nr_running && p->se.sleep_avg)
> 	rq->cache_hot_timeout = now + min(sysctl_sched_migration_cost, p->se.sleep_avg);
> 
> For tasks that have a large sleep_avg, it would activate this rq
> "appear as not idle for rq selection" scheme for a window of
> sysctl_sched_migration_cost. If the sleep ends up being a long one,
> preventing other tasks from being migrated to this rq for a tiny
> window should not matter performance-wise. I would expect that it
> could help workloads that come in bursts.
>

After a revist, I thought maybe above approach is better. Because
this method considers all the historic data rather than only the short
sleeping duration:

if ((flags & ENQUEUE_WAKEUP) && last_sleep && cpu_online(task_cpu(p)) &&
     now > last_sleep && now - last_sleep < sysctl_sched_migration_cost)
	update_avg(&p->se.burst_sleep_avg, now - last_sleep);

Say, if a task sleeps for 1 ms, and in all the subsequent context switch
it will sleep much longer than 1 ms, then the burst_avg_sleep will remain
1 ms which does not reflect the behavior of this task.

update_avg() is actually (Exponentially Weighted Moving-Average) of

new_avg = 0.875 * old_avg + 0.125 * lastest_sleep_duration

which approximately reflects the latest 1/0.125 = 8 sample data. I guess
the 8 is small enought to capture the burst sleep duration.

Unless we want to capture the scenario that, during the latest 8 sleep
events, there are 1 small sleeps, and 7 large sleep behavior and
we still want to honor that 1 small sleep and reserve the idle CPU.
Then either we can use the method you proposed to use the min logic, or
use the logic you proposed in another reply, but enhance it by clearing
that burst avergae sleep duration if there is a continious 8 long sleep
event, which looks a little overkilled. Anyway, I can get some data based
on this.

thanks,
Chenyu