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

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

Date:	Thu, 26 Mar 2015 10:21:24 +0000
From:	Juri Lelli <juri.lelli@....com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Morten Rasmussen <Morten.Rasmussen@....com>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
	Dietmar Eggemann <Dietmar.Eggemann@....com>,
	"yuyang.du@...el.com" <yuyang.du@...el.com>,
	"preeti@...ux.vnet.ibm.com" <preeti@...ux.vnet.ibm.com>,
	"mturquette@...aro.org" <mturquette@...aro.org>,
	"nico@...aro.org" <nico@...aro.org>,
	"rjw@...ysocki.net" <rjw@...ysocki.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFCv3 PATCH 33/48] sched: Energy-aware wake-up task placement

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/