Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34;
Date:   Wed, 11 Oct 2023 18:23:30 +0800
From:   Chen Yu <yu.c.chen@intel.com>
To:     Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
CC:     Peter Zijlstra <peterz@infradead.org>,
        <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@redhat.com>,
        Valentin Schneider <vschneid@redhat.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Ben Segall <bsegall@google.com>,
        "Mel Gorman" <mgorman@suse.de>,
        Daniel Bristot de Oliveira <bristot@redhat.com>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Juri Lelli <juri.lelli@redhat.com>,
        Swapnil Sapkal <Swapnil.Sapkal@amd.com>,
        Aaron Lu <aaron.lu@intel.com>, Tim Chen <tim.c.chen@intel.com>,
        K Prateek Nayak <kprateek.nayak@amd.com>,
        "Gautham R . Shenoy" <gautham.shenoy@amd.com>, <x86@kernel.org>
Subject: Re: [RFC PATCH] sched/fair: Bias runqueue selection towards almost
 idle prev CPU
Message-ID: <ZSZ3otWxbXWwmOGh@chenyu5-mobl2.ccr.corp.intel.com>
References: <20230929183350.239721-1-mathieu.desnoyers@efficios.com>
 <ZRfKKxBzfu+kf0tM@chenyu5-mobl2.ccr.corp.intel.com>
 <0f3cfff3-0df4-3cb7-95cb-ea378517e13b@efficios.com>
 <ZSORUczD6tp2fbe7@chenyu5-mobl2.ccr.corp.intel.com>
 <54d3a982-86e2-4317-a08f-a4eec0374227@efficios.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <54d3a982-86e2-4317-a08f-a4eec0374227@efficios.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?dhXt7BPmh1o4rjIrBdeaM8h0WU8+62jpCr2nqfEy4T5AbJchfktI1dymLcjA?=
 =?us-ascii?Q?CireN2VC67nj4i/gxqhRQvzMkmdJFyGzeMPAnlIhkzPWcuao2OnbazR2WQHf?=
 =?us-ascii?Q?oHErjAk90ClIQp27aBbrX4dE6Mt8rTHTHFk4sGO3T+TfGP3EFKLrtmoB3YYM?=
 =?us-ascii?Q?lGgVE7bcoPGkiksFLpzqsNp5wbO7+0hN4yTOyErMxd0y+DUNa7gPaHiX5Vzp?=
 =?us-ascii?Q?Jg/XUAoNjGrdAqbSjxQ+kx7qFM1m2QOCDDUyxR/XOhptSU76ZONBPRKGofZZ?=
 =?us-ascii?Q?/QmKfaHQa7cA2CWG/WAe84zy2DeT109/R9fxwU+0Be1/Cv47YXadfQSB7foV?=
 =?us-ascii?Q?vHgPN42gTUvIoE2tqfSAjcKZIEwMxQoYqGbeWGDQtyYFYfM3YH1PDXpJxNsd?=
 =?us-ascii?Q?63tkpfsqKQfMm0VhV+v5T+601gu8vkSyl+SK68ge2tC/9273V4SC3cnvEU/H?=
 =?us-ascii?Q?hx4B1mIrmhtLzOWJiyqEi7rZQTlvavS7mlFpmacoA5Sl6A2EQ+F/NBVc6cjw?=
 =?us-ascii?Q?7/9PcE93CKbm19yfjIoQH1dcObTicaXRQLBUY2naeWZLZJptRnFL/4QSVSWG?=
 =?us-ascii?Q?03qVyzMRJXwU9xvTfP3N1MijP6Htkv441Lro3fo6hBMmQuClkZieJVH9MJkj?=
 =?us-ascii?Q?/EH40JV5qvFf2c0gMp11gjdWCpioGgqay20jIRcgFa1TxQsyy+InM7MQrdeZ?=
 =?us-ascii?Q?AA5dXZal3A3/Olm1+LpBc6oE9TKdGwNbHQjKTyDsviOddhFMz22Izz+pLulJ?=
 =?us-ascii?Q?mrK0zKrMKIaA1LyiiIV5gy1qnqr1LApTgM2zoODCE57j1rclFzvBy/sL/a/a?=
 =?us-ascii?Q?xs20TFCS2D0tOZuJR7sZs8fpjLY0hsi9CT+cMVUOtZutgpJvlYN3jnhZnatm?=
 =?us-ascii?Q?Vi2JFYkgCGG1+7b28e+AwA4Z2D0gYjtpdMeO6JVmez88q2lhQoTg1FIPr0rZ?=
 =?us-ascii?Q?skGvSQZZX5JOcsVIZqHUDIAioTd5Y0JCk1OPPfPYw4Y+44w1S80ZVoCq7YMr?=
 =?us-ascii?Q?Y+fFRRwFLWKJPRrbaKGlcsmDRjXL27CmmYrN+n5XTVRAyh0KcgbpVkd5Zue7?=
 =?us-ascii?Q?80iAR2wkB1sif3THtpO8NdOCQK+KsnJ9iUSJFG9j4kruxrH0is6MjiAgCq4H?=
 =?us-ascii?Q?MJwvK7EvWyvTfDH4GqLkSv2XJoUVonk74IzXWjS1anyiXC7MHgo0XNsjjBPI?=
 =?us-ascii?Q?jAppyKb4M7ffKIiq4oVHk+k/5HWLPoB3fnWlFGlP5pwuOqqA2PG0X6ZPeEIY?=
 =?us-ascii?Q?6NCYzXaNTLBM96mNkSY9m4aAaLeZ3RZXcU+aYB9TiH3R+4Mpl8z5zDMZTcsU?=
 =?us-ascii?Q?9I9HJ/dfA9b/PJm54VF35XkyJBdXl4SVqi1WI/XAVtJrzaZPGr8kfsNmHd2B?=
 =?us-ascii?Q?KdureQpo149ntoxqfOu7nmj2EpX6geKt7+Xq8xKdmEgjOxJm0gX7JrOdYtLs?=
 =?us-ascii?Q?+/C5120VUDtSvYDteNy1LozxhhLFApPYl7/E4YNpzPYUDGNCKdGVaNTl6Irh?=
 =?us-ascii?Q?NmRt6fXkmwX6/SsZ5br+ZxjiDHW4oo7uQ7kJqfnwLmrFuHzJVesnY4XJCFCI?=
 =?us-ascii?Q?f0wQpPKFTk7ioS1LAL+SkKJLjaHXHmVXCiO/SThz?=
X-MS-Exchange-CrossTenant-Network-Message-Id: b55f321e-51f0-4bc7-b16d-08dbca44266e
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6206.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Oct 2023 10:23:45.5383
 (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: zsCfee7hRCu99jx9XyjtcrDB2LZufl/fzfcbawVHpiIrN/HK6GMzLXIus27SiK3bL0bor6l/4QVB4YVWh9583Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR11MB5287
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=2.7 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS autolearn=no
	autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.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 (howler.vger.email [0.0.0.0]); Wed, 11 Oct 2023 03:24:22 -0700 (PDT)
X-Spam-Level: **

On 2023-10-10 at 10:18:18 -0400, Mathieu Desnoyers wrote:
> On 2023-10-09 01:36, Chen Yu wrote:
> > On 2023-09-30 at 07:45:38 -0400, Mathieu Desnoyers wrote:
> > > On 9/30/23 03:11, Chen Yu wrote:
> > > > Hi Mathieu,
> > > > 
> > > > On 2023-09-29 at 14:33:50 -0400, Mathieu Desnoyers wrote:
> > > > > Introduce the WAKEUP_BIAS_PREV_IDLE scheduler feature. It biases
> > > > > select_task_rq towards the previous CPU if it was almost idle
> > > > > (avg_load <= 0.1%).
> > > > 
> > > > Yes, this is a promising direction IMO. One question is that,
> > > > can cfs_rq->avg.load_avg be used for percentage comparison?
> > > > If I understand correctly, load_avg reflects that more than
> > > > 1 tasks could have been running this runqueue, and the
> > > > load_avg is the direct proportion to the load_weight of that
> > > > cfs_rq. Besides, LOAD_AVG_MAX seems to not be the max value
> > > > that load_avg can reach, it is the sum of
> > > > 1024 * (y + y^1 + y^2 ... )
> > > > 
> > > > For example,
> > > > taskset -c 1 nice -n -20 stress -c 1
> > > > cat /sys/kernel/debug/sched/debug | grep 'cfs_rq\[1\]' -A 12 | grep "\.load_avg"
> > > >     .load_avg                      : 88763
> > > >     .load_avg                      : 1024
> > > > 
> > > > 88763 is higher than LOAD_AVG_MAX=47742
> > > 
> > > I would have expected the load_avg to be limited to LOAD_AVG_MAX somehow,
> > > but it appears that it does not happen in practice.
> > > 
> > > That being said, if the cutoff is really at 0.1% or 0.2% of the real max,
> > > does it really matter ?
> > > 
> > > > Maybe the util_avg can be used for precentage comparison I suppose?
> > > [...]
> > > > Or
> > > > return cpu_util_without(cpu_rq(cpu), p) * 1000 <= capacity_orig_of(cpu) ?
> > > 
> > > Unfortunately using util_avg does not seem to work based on my testing.
> > > Even at utilization thresholds at 0.1%, 1% and 10%.
> > > 
> > > Based on comments in fair.c:
> > > 
> > >   * CPU utilization is the sum of running time of runnable tasks plus the
> > >   * recent utilization of currently non-runnable tasks on that CPU.
> > > 
> > > I think we don't want to include currently non-runnable tasks in the
> > > statistics we use, because we are trying to figure out if the cpu is a
> > > idle-enough target based on the tasks which are currently running, for the
> > > purpose of runqueue selection when waking up a task which is considered at
> > > that point in time a non-runnable task on that cpu, and which is about to
> > > become runnable again.
> > > 
> > > 
> > 
> > Based on the discussion, another effort to inhit task migration is to make
> > WA_BIAS prefers previous CPU rather than the current CPU. However it did not
> > show much difference with/without this change applied. I think this is because
> > although wake_affine_weight() chooses the previous CPU, in select_idle_sibling()
> > it would still prefer the current CPU to the previous CPU if no idle CPU is detected.
> > Based on this I did the following changes in select_idle_sibling():
> > 
> > 1. When the system is underloaded, change the sequence of idle CPU checking.
> >     If both the target and previous CPU are idle, choose previous CPU first.
> 
> Are you suggesting that the patch below be used in combination with my
> "almost_idle" approach, or as a replacement ?
>

This patch is composed of two parts: the first one is to deal with underloaded
case, which is supposed to check if it could choose previous idle CPU over
an almost idle CPU. But according to your test, this does not have effect.
The second part is to deal with the overloaded case which I found that it
could bring benefit when the system is overloaded.
 
> I've tried my workload with only your patch, and the performances were close
> to the baseline (bad). With both patches combined, the performances are as
> good as with my almost_idle patch. This workload on my test machine has cpus
> at about 50% idle with the baseline.
> 

Yes, the benefit should come from the almost idle strategy.

> > 
> > 2. When the system is overloaded, and all CPUs are busy, choose the previous
> >     CPU over the target CPU.
> > 
> > hackbench -g 16 -f 20 -l 480000 -s 100
> > 
> > Before the patch:
> > Running in process mode with 16 groups using 40 file descriptors each (== 640 tasks)
> > Each sender will pass 480000 messages of 100 bytes
> > Time: 81.076
> > 
> > After the patch:
> > Running in process mode with 16 groups using 40 file descriptors each (== 640 tasks)
> > Each sender will pass 480000 messages of 100 bytes
> > Time: 77.527
> > 
> > track the task migration count in 10 seconds:
> > kretfunc:select_task_rq_fair
> > {
> >          $p = (struct task_struct *)args->p;
> >          if ($p->comm == "hackbench") {
> >                  if ($p->thread_info.cpu == retval) {
> >                          @wakeup_prev = count();
> >                  } else if (retval == cpu) {
> >                          @wakeup_curr = count();
> >                  } else {
> >                          @wakeup_migrate = count();
> >                  }
> >          }
> > }
> > 
> > Before the patch:
> > @wakeup_prev: 8369160
> > @wakeup_curr: 3624480
> > @wakeup_migrate: 523936
> > 
> > After the patch
> > @wakeup_prev: 15465952
> > @wakeup_curr: 214540
> > @wakeup_migrate: 65020
> > 
> > The percentage of wakeup on previous CPU has been increased from
> > 8369160 / (8369160 + 3624480 + 523936) = 66.85% to
> > 15465952 / (15465952 + 214540 + 65020) = 98.22%.
> 
> Those results are interesting. I wonder if this change negatively affects
> other workloads though.
>

I haven't tested other benchmarks yet and just to send this idea out. I could
launch more test to see if could bring other impact.
 
> > 
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index e2a69af8be36..9131cb359723 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -7264,18 +7264,20 @@ static int select_idle_sibling(struct task_struct *p, int prev, int target)
> >   	 */
> >   	lockdep_assert_irqs_disabled();
> > -	if ((available_idle_cpu(target) || sched_idle_cpu(target)) &&
> > -	    asym_fits_cpu(task_util, util_min, util_max, target))
> > -		return target;
> > -
> >   	/*
> >   	 * If the previous CPU is cache affine and idle, don't be stupid:
> > +	 * The previous CPU is checked prio to the target CPU to inhibit
> 
> prio -> prior
>

Thanks for pointing this out.

thanks,
Chenyu