Re: [RFCv5 PATCH 32/46] sched: Energy-aware wake-up task placement

Steve Muckle
2015-09-20T18:39:21Z

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