Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1228936

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

From Steve Muckle <steve.muckle@linaro.org>
Newsgroups linux.kernel
Subject Re: [RFCv5 PATCH 32/46] sched: Energy-aware wake-up task placement
Date 2015-09-20 20:40 +0200
Message-ID <qaRGN-7Ww-7@gated-at.bofh.it> (permalink)
References <pJFN0-Ef-15@gated-at.bofh.it> <pJFN1-Ef-33@gated-at.bofh.it> <q4jRv-33p-17@gated-at.bofh.it> <qa1fc-8td-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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

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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [RFCv5 PATCH 32/46] sched: Energy-aware wake-up task placement Dietmar Eggemann <dietmar.eggemann@arm.com> - 2015-09-18 12:40 +0200
  Re: [RFCv5 PATCH 32/46] sched: Energy-aware wake-up task placement Steve Muckle <steve.muckle@linaro.org> - 2015-09-20 20:40 +0200
    Re: [RFCv5 PATCH 32/46] sched: Energy-aware wake-up task placement Leo Yan <leo.yan@linaro.org> - 2015-09-21 00:10 +0200

csiph-web