lkml.org 
[lkml]   [2015]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFCv5 PATCH 32/46] sched: Energy-aware wake-up task placement
From
Date
On 09/18/2015 03:34 AM, Dietmar Eggemann wrote:
>> Here should consider scenario for two groups have same capacity?
>> This will benefit for the case LITTLE.LITTLE. So the code will be
>> looks like below:
>>
>> int target_sg_cpu = INT_MAX;
>>
>> if (capacity_of(max_cap_cpu) <= target_max_cap &&
>> task_fits_capacity(p, max_cap_cpu)) {
>>
>> if ((capacity_of(max_cap_cpu) == target_max_cap) &&
>> (target_sg_cpu < max_cap_cpu))
>> continue;
>>
>> target_sg_cpu = max_cap_cpu;
>> sg_target = sg;
>> target_max_cap = capacity_of(max_cap_cpu);
>> }
>>
>
> It's true that on your SMP system the target sched_group 'sg_target'
> depends only on 'task_cpu(p)' because this determines sched_domain 'sd'
> (and so the order of sched_groups for the iteration).
>
> So the current do-while loop to select 'sg_target' for an SMP system
> makes little sense.
>
> But why should we favour the first sched_group (cluster) (the one w/ the
> lower max_cap_cpu number) in this situation?

Running the originally proposed code on a system with two identical
clusters, it looks like we'll always end up doing an energy-aware search
in the task's prev_cpu cluster (sched_group). If you had small tasks
scattered across both clusters, energy_aware_wake_cpu() would not
consider condensing them on a single cluster. Leo was this the issue you
were seeing?

However I think there may be negative side effects with the proposed
policy above as well - won't this cause us to pack the first cluster
until it's 100% full (running at fmax) before using the second cluster?
That would also be bad for power.

thanks,
Steve



\
 
 \ /
  Last update: 2015-09-20 21:01    [W:0.132 / U:0.832 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site