linux-kernel - Re: [RFCv3 PATCH 17/48] sched: Get rid of scaling usage by cpu_capacity

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>] [day] [month] [year] [list]

Date:	Tue, 28 Apr 2015 17:54:38 +0100
From:	Dietmar Eggemann <dietmar.eggemann@....com>
To:	"pang.xunlei@....com.cn" <pang.xunlei@....com.cn>,
	Morten Rasmussen <Morten.Rasmussen@....com>
CC:	Juri Lelli <Juri.Lelli@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-kernel-owner@...r.kernel.org" 
	<linux-kernel-owner@...r.kernel.org>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"mturquette@...aro.org" <mturquette@...aro.org>,
	"nico@...aro.org" <nico@...aro.org>,
	"peterz@...radead.org" <peterz@...radead.org>,
	"preeti@...ux.vnet.ibm.com" <preeti@...ux.vnet.ibm.com>,
	"rjw@...ysocki.net" <rjw@...ysocki.net>,
	"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
	"yuyang.du@...el.com" <yuyang.du@...el.com>
Subject: Re: [RFCv3 PATCH 17/48] sched: Get rid of scaling usage by cpu_capacity_orig

On 28/04/15 08:12, pang.xunlei@....com.cn wrote:
> Morten Rasmussen <morten.rasmussen@....com>  wrote 2015-02-05 AM 02:30:54:
>> From: Dietmar Eggemann <dietmar.eggemann@....com>
>>
>> Since now we have besides frequency invariant also cpu (uarch plus max
>> system frequency) invariant cfs_rq::utilization_load_avg both, frequency
>> and cpu scaling happens as part of the load tracking.
>> So cfs_rq::utilization_load_avg does not have to be scaled by the original
>> capacity of the cpu again.
>>
>> Cc: Ingo Molnar <mingo@...hat.com>
>> Cc: Peter Zijlstra <peterz@...radead.org>
>> Signed-off-by: Dietmar Eggemann <dietmar.eggemann@....com>
>> ---
>>  kernel/sched/fair.c | 5 ++---
>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 5375ab1..a85c34b 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -4807,12 +4807,11 @@ static int select_idle_sibling(struct
>> task_struct *p, int target)
>>  static int get_cpu_usage(int cpu)
>>  {
>>     unsigned long usage = cpu_rq(cpu)->cfs.utilization_load_avg;
>> -   unsigned long capacity = capacity_orig_of(cpu);
>>  
>>     if (usage >= SCHED_LOAD_SCALE)
> 
> Since utilization_load_avg has been applied all the scaling,
> it can't exceed its original capacity. SCHED_LOAD_SCALE is
> the max original capacity of all, right?
> 
> So, shouldn't this be "if(usage >= orig_capacity)"?

Absolutely, you're right. The usage on cpus which have a smaller orig
capacity (<1024) than the cpus with the highest orig capacity (1024)
have to be limited to their orig capacity.

There is another patch in this series '[RFCv3 PATCH 28/48] sched: Use
capacity_curr to cap utilization in get_cpu_usage()' which changes the
upper bound from SCHED_LOAD_SCALE to capacity_curr_of(cpu) and returns
this current capacity in case the usage (running and blocked) exceeds it.

Our testing in the meantime has shown that this is the wrong approach in
some cases. Like adding more tasks to a cpu and deciding the new
capacity state (OPP) based on get_cpu_usage(). We are likely to change
this to capacity_orig_of(cpu) in the next version.

[...]

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/