linux-kernel - Re: [PATCH v5 2/3] sched/topology: Rework CPU capacity asymmetry detection

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: <315b4b5d-05f5-e311-8ed9-b55072cf84f9@arm.com>
Date:   Thu, 27 May 2021 14:22:52 +0200
From:   Dietmar Eggemann <dietmar.eggemann@....com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Beata Michalska <beata.michalska@....com>,
        Valentin Schneider <valentin.schneider@....com>,
        linux-kernel@...r.kernel.org, mingo@...hat.com,
        juri.lelli@...hat.com, vincent.guittot@...aro.org, corbet@....net,
        rdunlap@...radead.org, linux-doc@...r.kernel.org
Subject: Re: [PATCH v5 2/3] sched/topology: Rework CPU capacity asymmetry
 detection

On 27/05/2021 09:03, Peter Zijlstra wrote:
> On Wed, May 26, 2021 at 11:52:25AM +0200, Dietmar Eggemann wrote:
> 
>> For me asym_cpu_capacity_classify() is pretty hard to digest ;-) But I
>> wasn't able to break it. It also performs correctly on (non-existing SMT)
>> layer (with sd span eq. single CPU).
> 
> This is the simplest form I could come up with this morning:
> 
> static inline int
> asym_cpu_capacity_classify(struct sched_domain *sd,
>                           const struct cpumask *cpu_map)
> {
> 	struct asym_cap_data *entry;
> 	int i = 0, n = 0;
> 
> 	list_for_each_entry(entry, &asym_cap_list, link) {
> 		if (cpumask_intersects(sched_domain_span(sd), entry->cpu_mask))
> 			i++;
> 		else
> 			n++;
> 	}
> 
> 	if (WARN_ON_ONCE(!i) || i == 1) /* no asymmetry */
> 		return 0;
> 
> 	if (n) /* partial asymmetry */
> 		return SD_ASYM_CPUCAPACITY;
> 
> 	/* full asymmetry */
> 	return SD_ASYM_CPUCAPACITY | SD_ASYM_CPUCAPACITY_FULL;
> }
> 
> 
> The early termination and everything was cute; but this isn't
> performance critical code and clarity is paramount.

This is definitely easier to grasp.

What about the missing `if (cpumask_intersects(entry->cpu_mask,
cpu_map))` condition in the else path to increment n?

Example:

cpus = {[446 446] [871 871] [1024 1024]}

So 3 asym_cap_list entries.

After hp'ing out CPU4 and CPU5:

DIE: 'partial asymmetry'

In case we would increment n only when the condition is met, we would
have `full asymmetry`.

I guess we want to allow EAS task placement, hence have
sd_asym_cpucapacity set in case there are only 446 and 871 left?