Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5;
Date:   Thu, 19 Oct 2023 19:35:40 +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 1/2] sched/fair: Introduce UTIL_FITS_CAPACITY feature
Message-ID: <ZTEUjBgthYhz7NXm@chenyu5-mobl2.ccr.corp.intel.com>
References: <20231018204511.1563390-1-mathieu.desnoyers@efficios.com>
 <20231018204511.1563390-2-mathieu.desnoyers@efficios.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20231018204511.1563390-2-mathieu.desnoyers@efficios.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?TunmnI9HTj8mt5sIQKZSa2H/JivygLhzq3neSe4rj6F5rG15RZMvrjYx2WL2?=
 =?us-ascii?Q?QmVp4Utpenmp/s0Ju7NrA5oFvZLZP+IwhFnIUgOi2oyCj3/J/WFBB1CE2+9J?=
 =?us-ascii?Q?DlbTKNzZqHMqXDTNvtxUxj20KY2zn/7oNzbtjF5QwVLKpmnjm4+hOBSjLDRN?=
 =?us-ascii?Q?HHQ4h63sHJZE6EB5KFdQcZYGtzDzokiBegX81nXQqlqtE0AoNavbOprwjK0a?=
 =?us-ascii?Q?WwU4wnPWbP8/gMsP3xCvrzdDFrmLL/crei0zVnyK57BQYVxIIRG4PjdCGaa4?=
 =?us-ascii?Q?AIgnS7u4pSLog19AUwJsQWa7yEjcBFnm88n3MKdai3mGIj8GrUSXVHfLTHEg?=
 =?us-ascii?Q?lqbGnMyATsIZGhcrUhG45s64wg4p6qzpXxLrJAN0GHnW6KSZRS9Zqq1hAqN2?=
 =?us-ascii?Q?oACNdGwRR6LLUvtvb2LGAU4brUm48vfvuwb94+13c//4RDXS/BX3rzAj1hZ9?=
 =?us-ascii?Q?fKCQVv9irjYJR1W+VZA1RZPtUeVqm9sEjweQgfy6NRf+hnf005rj72nUa4VJ?=
 =?us-ascii?Q?xY6sQ0XeK7r929oNTNpvCn1Geiq3eR3hPhRqa8Z4Wfstu9Q/3xHEtSvXOV5G?=
 =?us-ascii?Q?YjQMei45sSDUu0Q8s1ZRtmvdMDSrDPTNQFAn+PzMZmx79j0Z/Mfd0sO+52SC?=
 =?us-ascii?Q?SqJQgjc6YpdhkeV4hQeLV5J4atILB7sDMciSps2W4gVWUXtZcINcNihdaS9q?=
 =?us-ascii?Q?zRAFlBhX3DHnvBABfuJLszMmeMMpbj6+jyq4txu6nB7MvfgGPRz9OnPpXLlf?=
 =?us-ascii?Q?P0dZpsSDeT/PZhG9QIyW28sfWiNcZcKNy0hgYzsnnsfe04xJaTR9yPgl8gy0?=
 =?us-ascii?Q?o4LraqJnw8EoYJbU/lw6BuEiwFUmArr8+3LOlqFr27JvSRVr4h/c6n+cj68H?=
 =?us-ascii?Q?QVimCkgHeavWkRqOaZ+nORk4hrrArMVTXCY9dgwxsaxfGVhB7++914vJy4jc?=
 =?us-ascii?Q?XyvKyFSYVISpWrurxqrBQEaU8kZo8MJECm9ESxDbL8yr8+twAZ7nls5q1pPo?=
 =?us-ascii?Q?BEUNM+YNUSpXxkXHlxRZ3yGr/GUsY6b6usx8EAgCuQDsyySisxs29VAf8CRI?=
 =?us-ascii?Q?ZmPwQTtsT8oQdRYWFaOg/KoHc9Et5w1ayKcOhmHsyNOMFsQDtdeVLia8s1U4?=
 =?us-ascii?Q?ckBxCMTKKOvJJCcrSIlcltbyCESe6SuVhC9Rgl7fz/pTv0t0wuUgu6AGl1xZ?=
 =?us-ascii?Q?K4YDa1k/hftSyfadIjk/h59IfteCPLYmt7p0UgJSo0hsrIdio/jgG+rq6eGg?=
 =?us-ascii?Q?uIks/5Fal7UKqi7Wc0obpNIfCczAYZqrPyHz4z1Tcg57CdmZMXFFU0vh/UJz?=
 =?us-ascii?Q?tOw7po2k94T+++tG1xYbw5hg8s0DZqvQnltf8tXHfICFBqBhUXeUbXoRN6Ff?=
 =?us-ascii?Q?zTNdoKxOJRH+MGhBg9F8eXwaneojLuCO3RK5M5ZlxTzAQ+w4Wnk9rorvwRCF?=
 =?us-ascii?Q?JI0KRc/o1xxMnN+38KEWTNNcT6rXyjw7Ojgg8QEig200HkeY9NzKGclRZoI1?=
 =?us-ascii?Q?tgIi7j42pPxZJstsB2qWAVBX9iXOyS8aCj/pbxGXED6SoBUkxpbmpFo2J8Ok?=
 =?us-ascii?Q?SqT5OlVaju1byIFlb0vlS4xDab7BX+sICOyjX819?=
X-MS-Exchange-CrossTenant-Network-Message-Id: bd0b1e08-f748-4cc8-087d-08dbd0978e04
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6206.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2023 11:35:54.5808
 (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: oLu231/pybgc79CVuXEEo+A2+p3vmpQe/vV3hyLb/50119j+qEr1iFCG/yRi5m4utcxWMDFnDPvbWkQSqnr2lQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR11MB7267
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 groat.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 (groat.vger.email [0.0.0.0]); Thu, 19 Oct 2023 04:36:19 -0700 (PDT)

On 2023-10-18 at 16:45:10 -0400, Mathieu Desnoyers wrote:
> Introduce the UTIL_FITS_CAPACITY scheduler feature. The runqueue
> selection picks the previous, target, or recent runqueues if they have
> enough remaining capacity to enqueue the task before scanning for an
> idle cpu.
> 
> This feature is introduced in preparation for the SELECT_BIAS_PREV
> scheduler feature. Its performance benefits are noticeable when combined
> with the SELECT_BIAS_PREV feature.
> 
> The following benchmarks only cover the UTIL_FITS_CAPACITY feature.
> Those are performed on a v6.5.5 kernel with mitigations=off.
> 
> The following hackbench workload on a 192 cores AMD EPYC 9654 96-Core
> Processor (over 2 sockets) keeps relatively the same wall time (49s).
> 
> hackbench -g 32 -f 20 --threads --pipe -l 480000 -s 100
> 
> We can observe that the number of migrations is reduced significantly
> with this patch (improvement):
> 
> Baseline:      117M cpu-migrations  (9.355 K/sec)
> With patch:     67M cpu-migrations  (5.470 K/sec)
> 
> The task-clock utilization is reduced (degradation):
> 
> Baseline:      253.275 CPUs utilized
> With patch:    223.130 CPUs utilized
> 
> The number of context-switches is increased (degradation):
> 
> Baseline:      445M context-switches (35.516 K/sec)
> With patch:    581M context-switches (47.548 K/sec)
> 
> So the improvement due to reduction of migrations is countered by the
> degradation in CPU utilization and context-switches. The following
> SELECT_BIAS_PREV feature will address this.
> 
> Link: https://lore.kernel.org/r/09e0f469-a3f7-62ef-75a1-e64cec2dcfc5@amd.com
> Link: https://lore.kernel.org/lkml/20230725193048.124796-1-mathieu.desnoyers@efficios.com/
> Link: https://lore.kernel.org/lkml/20230810140635.75296-1-mathieu.desnoyers@efficios.com/
> Link: https://lore.kernel.org/lkml/20230810140635.75296-1-mathieu.desnoyers@efficios.com/
> Link: https://lore.kernel.org/lkml/f6dc1652-bc39-0b12-4b6b-29a2f9cd8484@amd.com/
> Link: https://lore.kernel.org/lkml/20230822113133.643238-1-mathieu.desnoyers@efficios.com/
> Link: https://lore.kernel.org/lkml/20230823060832.454842-1-aaron.lu@intel.com/
> Link: https://lore.kernel.org/lkml/20230905171105.1005672-1-mathieu.desnoyers@efficios.com/
> Link: https://lore.kernel.org/lkml/cover.1695704179.git.yu.c.chen@intel.com/
> Link: https://lore.kernel.org/lkml/20230929183350.239721-1-mathieu.desnoyers@efficios.com/
> Link: https://lore.kernel.org/lkml/20231012203626.1298944-1-mathieu.desnoyers@efficios.com/
> Link: https://lore.kernel.org/lkml/20231017221204.1535774-1-mathieu.desnoyers@efficios.com/
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Valentin Schneider <vschneid@redhat.com>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Ben Segall <bsegall@google.com>
> Cc: Mel Gorman <mgorman@suse.de>
> Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
> Cc: Vincent Guittot <vincent.guittot@linaro.org>
> Cc: Juri Lelli <juri.lelli@redhat.com>
> Cc: Swapnil Sapkal <Swapnil.Sapkal@amd.com>
> Cc: Aaron Lu <aaron.lu@intel.com>
> Cc: Chen Yu <yu.c.chen@intel.com>
> Cc: Tim Chen <tim.c.chen@intel.com>
> Cc: K Prateek Nayak <kprateek.nayak@amd.com>
> Cc: Gautham R . Shenoy <gautham.shenoy@amd.com>
> Cc: x86@kernel.org
> ---
>  kernel/sched/fair.c     | 49 ++++++++++++++++++++++++++++++++++++-----
>  kernel/sched/features.h |  6 +++++
>  kernel/sched/sched.h    |  5 +++++
>  3 files changed, 54 insertions(+), 6 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 1d9c2482c5a3..8058058afb11 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4497,6 +4497,37 @@ static inline void util_est_update(struct cfs_rq *cfs_rq,
>  	trace_sched_util_est_se_tp(&p->se);
>  }
>  
> +/*
> + * Returns true if adding the task utilization to the estimated
> + * utilization of the runnable tasks on @cpu does not exceed the
> + * capacity of @cpu.
> + *
> + * This considers only the utilization of _runnable_ tasks on the @cpu
> + * runqueue, excluding blocked and sleeping tasks. This is achieved by
> + * using the runqueue util_est.enqueued, and by estimating the capacity
> + * of @cpu based on arch_scale_cpu_capacity and arch_scale_thermal_pressure
> + * rather than capacity_of() because capacity_of() considers
> + * blocked/sleeping tasks in other scheduler classes.
> + *
> + * The utilization vs capacity comparison is done without the margin
> + * provided by fits_capacity(), because fits_capacity() is used to
> + * validate whether the utilization of a task fits within the overall
> + * capacity of a cpu, whereas this function validates whether the task
> + * utilization fits within the _remaining_ capacity of the cpu, which is
> + * more precise.
> + */
> +static inline bool task_fits_remaining_cpu_capacity(unsigned long task_util,
> +						    int cpu)
> +{
> +	unsigned long total_util, capacity;
> +
> +	if (!sched_util_fits_capacity_active())
> +		return false;
> +	total_util = READ_ONCE(cpu_rq(cpu)->cfs.avg.util_est.enqueued) + task_util;
> +	capacity = arch_scale_cpu_capacity(cpu) - arch_scale_thermal_pressure(cpu);

scale_rt_capacity(cpu) could provide the remaining cpu capacity after substracted by
the side activity(rt tasks/thermal pressure/irq time), maybe it would be more accurate?

> +	return total_util <= capacity;
> +}
> +
>  static inline int util_fits_cpu(unsigned long util,
>  				unsigned long uclamp_min,
>  				unsigned long uclamp_max,
> @@ -7124,12 +7155,15 @@ static int select_idle_sibling(struct task_struct *p, int prev, int target)
>  	int i, recent_used_cpu;
>  
>  	/*
> -	 * On asymmetric system, update task utilization because we will check
> -	 * that the task fits with cpu's capacity.
> +	 * With the UTIL_FITS_CAPACITY feature and on asymmetric system,
> +	 * update task utilization because we will check that the task
> +	 * fits with cpu's capacity.
>  	 */
> -	if (sched_asym_cpucap_active()) {
> +	if (sched_util_fits_capacity_active() || sched_asym_cpucap_active()) {
>  		sync_entity_load_avg(&p->se);
>  		task_util = task_util_est(p);
> +	}
> +	if (sched_asym_cpucap_active()) {
>  		util_min = uclamp_eff_value(p, UCLAMP_MIN);
>  		util_max = uclamp_eff_value(p, UCLAMP_MAX);
>  	}
> @@ -7139,7 +7173,8 @@ 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)) &&
> +	if ((available_idle_cpu(target) || sched_idle_cpu(target) ||
> +	    task_fits_remaining_cpu_capacity(task_util, target)) &&

Compared to the previous version posted here[1], when the cpu's util_est is lower than 25% of CPU
capacity we choose the previous CPU, current version seems to be more aggressive.
it is possible that a short running task is queued on the near 100% busy cpu while there
is still an idle cpu in the system.

https://lore.kernel.org/lkml/20231017221204.1535774-1-mathieu.desnoyers@efficios.com/

thanks,
Chenyu