linux-kernel - Re: [PATCH v3 1/3] sched/fair: Add asymmetric CPU capacity wakeup scan

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]

Date:   Wed, 29 Jan 2020 11:38:37 +0100
From:   Dietmar Eggemann <dietmar.eggemann@....com>
To:     Valentin Schneider <valentin.schneider@....com>,
        Pavan Kondeti <pkondeti@...eaurora.org>
Cc:     linux-kernel@...r.kernel.org, mingo@...hat.com,
        peterz@...radead.org, vincent.guittot@...aro.org,
        morten.rasmussen@....com, qperret@...gle.com,
        adharmap@...eaurora.org
Subject: Re: [PATCH v3 1/3] sched/fair: Add asymmetric CPU capacity wakeup
 scan

On 28/01/2020 12:30, Valentin Schneider wrote:
> Hi Pavan,
> 
> On 28/01/2020 06:22, Pavan Kondeti wrote:
>> Hi Valentin,
>>
>> On Sun, Jan 26, 2020 at 08:09:32PM +0000, Valentin Schneider wrote:

[...]

>>> +
>>> +	if (!static_branch_unlikely(&sched_asym_cpucapacity))
>>> +		return -1;

We do need this one to bail out quickly on non CPU asym systems. (1)

>>> +	sd = rcu_dereference(per_cpu(sd_asym_cpucapacity, target));
>>> +	if (!sd)
>>> +		return -1;

And I assume we can't return target here because of exclusive cpusets
which can form symmetric CPU capacities islands on a CPU asymmetric
system? (2)

>>> +	sync_entity_load_avg(&p->se);
>>> +
>>> +	cpus = this_cpu_cpumask_var_ptr(select_idle_mask);
>>> +	cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr);
>>> +
>>> +	for_each_cpu_wrap(cpu, cpus, target) {
>>> +		rq = cpu_rq(cpu);
>>> +
>>> +		if (!available_idle_cpu(cpu))
>>> +			continue;
>>> +		if (task_fits_capacity(p, rq->cpu_capacity))
>>> +			return cpu;
>>
>> I have couple of questions.

[...]

>> (2) Assuming all CPUs are busy, we return -1 from here and end up
>> calling select_idle_cpu(). The traversal in select_idle_cpu() may be
>> waste in cases where sd_llc == sd_asym_cpucapacity . For example SDM845.
>> Should we worry about this?
>>
> 
> Before v3, since we didn't have the fallback CPU selection within
> select_idle_capacity(), we would need the fall-through to select_idle_cpu()
> (we could've skipped an idle CPU just because its capacity wasn't high
> enough).
> 
> That's not the case anymore, so indeed we may be able to bail out of
> select_idle_sibling() right after select_idle_capacity() (or after the
> prev / recent_used_cpu checks). Our only requirement here is that sd_llc
> remains a subset of sd_asym_cpucapacity.

How do you distinguish '-1' in (1), (2) and 'best_cpu = -1' (3)?

In (1) and (2) you want to check if target is idle (or sched_idle) but
in (3) you probably only want to check 'recent_used_cpu'?