linux-kernel - Re: [PATCH v3 1/7] sched: limit cpu search in select_idle

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]

Message-ID: <e8dc35a9-f46a-b83d-fb7d-f8284ba712c6@oracle.com>
Date:   Fri, 28 Jun 2019 15:21:08 -0700
From:   Subhra Mazumdar <subhra.mazumdar@...cle.com>
To:     Parth Shah <parth@...ux.ibm.com>, linux-kernel@...r.kernel.org
Cc:     peterz@...radead.org, mingo@...hat.com, tglx@...utronix.de,
        steven.sistare@...cle.com, dhaval.giani@...cle.com,
        daniel.lezcano@...aro.org, vincent.guittot@...aro.org,
        viresh.kumar@...aro.org, tim.c.chen@...ux.intel.com,
        mgorman@...hsingularity.net
Subject: Re: [PATCH v3 1/7] sched: limit cpu search in select_idle_cpu


On 6/28/19 11:47 AM, Parth Shah wrote:
>
> On 6/27/19 6:59 AM, subhra mazumdar wrote:
>> Put upper and lower limit on cpu search of select_idle_cpu. The lower limit
>> is amount of cpus in a core while upper limit is twice that. This ensures
>> for any architecture we will usually search beyond a core. The upper limit
>> also helps in keeping the search cost low and constant.
>>
>> Signed-off-by: subhra mazumdar <subhra.mazumdar@...cle.com>
>> ---
>>   kernel/sched/fair.c | 15 +++++++++++----
>>   1 file changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index f35930f..b58f08f 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -6188,7 +6188,7 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int t
>>   	u64 avg_cost, avg_idle;
>>   	u64 time, cost;
>>   	s64 delta;
>> -	int cpu, nr = INT_MAX;
>> +	int cpu, limit, floor, nr = INT_MAX;
>>
>>   	this_sd = rcu_dereference(*this_cpu_ptr(&sd_llc));
>>   	if (!this_sd)
>> @@ -6206,10 +6206,17 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int t
>>
>>   	if (sched_feat(SIS_PROP)) {
>>   		u64 span_avg = sd->span_weight * avg_idle;
>> -		if (span_avg > 4*avg_cost)
>> +		floor = cpumask_weight(topology_sibling_cpumask(target));
>> +		if (floor < 2)
>> +			floor = 2;
>> +		limit = floor << 1;
> Is upper limit an experimental value only or it has any arch specific significance?
> Because, AFAIU, systems like POWER9 might have benefit for searching for 4-cores
> due to its different cache model. So it can be tuned for arch specific builds then.
The lower bound and upper bound were 1 core and 2 core respectively. That
is done as to search beyond one core and at the same time not to search
too much. It is heuristic that seemed to work well on all archs coupled
with the moving window mechanism. Does 4 vs 2 make any difference on your
POWER9? AFAIR it didn't on SPARC SMT8.
>
> Also variable names can be changed for better readability.
> floor -> weight_clamp_min
> limit -> weight_clamp_max
> or something similar
OK.

Thanks,
Subhra
>
>
>> +		if (span_avg > floor*avg_cost) {
>>   			nr = div_u64(span_avg, avg_cost);
>> -		else
>> -			nr = 4;
>> +			if (nr > limit)
>> +				nr = limit;
>> +		} else {
>> +			nr = floor;
>> +		}
>>   	}
>>
>>   	time = local_clock();
>>
>
> Best,
> Parth
>