linux-kernel - Re: [RFCv3 PATCH 29/48] sched: Highest energy aware balancing sched

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]

Message-ID: <20150324105259.GD18994@e105550-lin.cambridge.arm.com>
Date:	Tue, 24 Mar 2015 10:52:59 +0000
From:	Morten Rasmussen <morten.rasmussen@....com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	"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 29/48] sched: Highest energy aware balancing
 sched_domain level pointer

On Mon, Mar 23, 2015 at 04:16:06PM +0000, Peter Zijlstra wrote:
> On Wed, Feb 04, 2015 at 06:31:06PM +0000, Morten Rasmussen wrote:
> > Add another member to the family of per-cpu sched_domain shortcut
> > pointers. This one, sd_ea, points to the highest level at which energy
> > model is provided. At this level and all levels below all sched_groups
> > have energy model data attached.
> 
> Here might be a good point to discuss what it means for the topology to
> have partial energy model information.

Partial energy model information is supported as in you can have energy
model data for just lower level sched domains and leave scheduling
between higher level sched_domains to be done the non-energy-aware
(current) way. For example, have energy-aware scheduling working within
each socket on a multi-socket system and let normal performance
(spreading) load-balancing work between sockets. Or within a NUMA node
and not between NUMA nodes as I mentioned in my reply to the next patch.
--
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/