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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 24 Mar 2015 15:24:42 +0000
From:	Morten Rasmussen <morten.rasmussen@....com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Sai Gurrappadi <sgurrappadi@...dia.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>,
	Juri Lelli <Juri.Lelli@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFCv3 PATCH 33/48] sched: Energy-aware wake-up task placement

On Tue, Mar 24, 2015 at 01:00:00PM +0000, Peter Zijlstra wrote:
> On Mon, Mar 16, 2015 at 02:47:23PM +0000, Morten Rasmussen wrote:
> > > Also, this heuristic for determining sg_target is a big little
> > > assumption. I don't think it is necessarily correct to assume that this
> > > is true for all platforms. This heuristic should be derived from the
> > > energy model for the platform instead.
> > 
> > I have had the same thought, but I ended up making that assumption since
> > I holds for the for the few platforms I have data for and it simplified
> > the code a lot. I think we can potentially remove this assumption later.
> 
> So the thing is; if we know all the possible behavioural modes of our
> system we could pre compute which are applicable to the system at hand.
> 
> All we need is a semi formal definition of our model and a friendly
> mathematician who can do the bifurcation analysis to find the modal
> boundaries and their parameters.
> 
> I suspect there is a limited number of modes and parameters and if we
> implement all we just need to select the right ones, this could save a
> lot of runtime computation.
> 
> But yes, we don't need to start with that, we can do the brute force
> thing for a while.

Yes, I think we need to get the basics (which are already quite
complicated) right before we start optimizing. Though, depending on how
crazy the energy model looks like, it should be possible to assign some
energy 'priority' to each group when the sched_domain hierarchy is built
based on the energy model data rather than basing the choice on max
capacity. At least until we find a friendly mathematician willing to
help us out :) 
--
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/