linux-kernel - Re: [PATCH v2 05/13] sched: Enable SD_BALANCE

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 11 Jul 2016 12:04:49 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Morten Rasmussen <morten.rasmussen@....com>
Cc:	mingo@...hat.com, dietmar.eggemann@....com, yuyang.du@...el.com,
	vincent.guittot@...aro.org, mgalbraith@...e.de,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 05/13] sched: Enable SD_BALANCE_WAKE for asymmetric
 capacity systems

On Wed, Jun 22, 2016 at 06:03:16PM +0100, Morten Rasmussen wrote:
> Systems with the SD_ASYM_CPUCAPACITY flag set indicate that sched_groups
> at this level or below do not include cpus of all capacities available
> (e.g. group containing little-only or big-only cpus in big.LITTLE
> systems). It is therefore necessary to put in more effort in finding an
> appropriate cpu at task wake-up by enabling balancing at wake-up
> (SD_BALANCE_WAKE).

> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -6397,6 +6397,9 @@ sd_init(struct sched_domain_topology_level *tl, int cpu)
>  	 * Convert topological properties into behaviour.
>  	 */
>  
> +	if (sd->flags & SD_ASYM_CPUCAPACITY)
> +		sd->flags |= SD_BALANCE_WAKE;
> +

So I'm a bit confused on the exact requirements for this; as also per
the previous patch.

Should all sched domains get BALANCE_WAKE if one (typically the top)
domain has ASYM_CAP set?

The previous patch set it on the actual asym one and one below that, but
what if there's more levels below that? Imagine ARM gaining SMT or
somesuch. Should not then that level also get BALANCE_WAKE in order to
'correctly' place light/heavy tasks?

IOW, are you trying to fudge the behaviour semantics by creating 'weird'
ASYM_CAP rules instead of having a more complex behaviour rule here?