linux-kernel - Re: [RFC PATCH 04/16] sched/fair: Remove magic hardcoded margin in fits

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2544d644-d107-49a7-a64e-25334315b51a@arm.com>
Date: Tue, 17 Sep 2024 21:41:25 +0200
From: Dietmar Eggemann <dietmar.eggemann@....com>
To: "Sultan Alsawaf (unemployed)" <sultan@...neltoast.com>,
 Qais Yousef <qyousef@...alina.io>
Cc: Ingo Molnar <mingo@...nel.org>, Peter Zijlstra <peterz@...radead.org>,
 Vincent Guittot <vincent.guittot@...aro.org>,
 "Rafael J. Wysocki" <rafael@...nel.org>,
 Viresh Kumar <viresh.kumar@...aro.org>, Juri Lelli <juri.lelli@...hat.com>,
 Steven Rostedt <rostedt@...dmis.org>, John Stultz <jstultz@...gle.com>,
 linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 04/16] sched/fair: Remove magic hardcoded margin in
 fits_capacity()

On 22/08/2024 07:09, Sultan Alsawaf (unemployed) wrote:
> Hi Qais,
> 
> On Tue, Aug 20, 2024 at 05:35:00PM +0100, Qais Yousef wrote:
>> Replace hardcoded margin value in fits_capacity() with better dynamic
>> logic.
>>
>> 80% margin is a magic value that has served its purpose for now, but it
>> no longer fits the variety of systems that exist today. If a system is
>> over powered specifically, this 80% will mean we leave a lot of capacity
>> unused before we decide to upmigrate on HMP system.
>>
>> On many systems the little cores are under powered and ability to
>> migrate faster away from them is desired.
>>
>> Redefine misfit migration to mean the utilization threshold at which the
>> task would become misfit at the next load balance event assuming it
>> becomes an always running task.
>>
>> To calculate this threshold, we use the new approximate_util_avg()
>> function to find out the threshold, based on arch_scale_cpu_capacity()
>> the task will be misfit if it continues to run for a TICK_USEC which is
>> our worst case scenario for when misfit migration will kick in.

[...]

>> +	/*
>> +	 * Calculate the util at which the task must be considered a misfit.
>> +	 *
>> +	 * We must ensure that a task experiences the same ramp-up time to
>> +	 * reach max performance point of the system regardless of the CPU it
>> +	 * is running on (due to invariance, time will stretch and task will
>> +	 * take longer to achieve the same util value compared to a task
>> +	 * running on a big CPU) and a delay in misfit migration which depends
>> +	 * on TICK doesn't end up hurting it as it can happen after we would
>> +	 * have crossed this threshold.
>> +	 *
>> +	 * To ensure that invaraince is taken into account, we don't scale time
>> +	 * and use it as-is, approximate_util_avg() will then let us know the
>> +	 * our threshold.
>> +	 */
>> +	limit = approximate_runtime(arch_scale_cpu_capacity(cpu)) * USEC_PER_MSEC;
> 
> Perhaps it makes more sense to use `capacity` here instead of
> `arch_scale_cpu_capacity(cpu)`? Seems like reduced capacity due to HW pressure
> (and IRQs + RT util) should be considered, e.g. for a capacity inversion due to
> HW pressure on a mid core that results in a little core being faster.

If you want to keep it strictly 'uarch & freq-invariant' based, then it
wouldn't have to be called periodically in update_cpu_capacity(). Just
set rq->fits_capacity_threshold once after cpu_scale has been fully
(uArch & Freq) normalized.

[...]