Re: [RFCv3 PATCH 33/48] sched: Energy-aware wake-up task placement

[Juri Lelli]

On 25/03/15 18:14, Peter Zijlstra wrote:
> On Wed, Mar 25, 2015 at 06:01:22PM +0000, Juri Lelli wrote:
> 
>> Yes and no, IMHO. It makes perfect sense to trigger cpufreq on the
>> target_cpu's freq domain, as we know that we are going to add p's
>> utilization there.
> 
> Fair point; I mainly wanted to start this discussion so that seems to
> have been a success :-)
> 
>> Anyway, I was thinking that we could just
>> rely on triggering points in {en,de}queue_task_fair and task_tick_fair.
>> We end up calling one of them every time we wake-up a task, perform
>> a load balancing decision or just while running the task itself
>> (we have to react to tasks phase changes). This way we should be
>> able to reduce the number of triggering points and be more general
>> at the same time.
> 
> The one worry I have with that is that it might need to re-compute which
> P state to request, where in the above (now trimmed quoted) code we
> already figured out which P state we needed to be in, any hook in
> enqueue would have forgotten that.
>

Right. And we currently have some of this re-compute needs. The reason
why I thought we could still give a try to this approach comes from a
few points:

 - we can't be fully synchronous yet (cpufreq drivers might sleep) and
   if we rely on some asynchronous entity to actually do the freq change
   we might already defeat the purpose of passing any sort of guidance
   to it (as things can be changed a lot by the time he has to take a
   decision); of course, once we'll get there things will change :)

 - how do we cope with codepaths that don't rely on usage for taking
   decisions? I guess we'll have to modify those to be able to drive
   cpufreq, or we could just trade some re-compute burden with this need

 - what about other sched classes? I know that this is very premature,
   but I can help but thinking that we'll need to do some sort of
   aggregation of requests, and if we put triggers in very specialized
   points we might lose some of the sched classes separation

Anyway, I'd say we try to look at what we have and then move forward
from there :).

Thanks!

- Juri

>>> So does it make sense to at least put in the right hooks now? I realize
>>> we'll likely take cpufreq out back and feed it to the bears but
>>> something managing P states will be there whatever we'll call the new
>>> fangled thing and this would be the place to hook it still.
>>>
>>
>> We should be able to clean up and post something along this line
>> fairly soon.
> 
> Grand!
> 

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