linux-kernel - Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

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:	Wed, 24 Jul 2013 14:50:11 +0100
From:	Morten Rasmussen <morten.rasmussen@....com>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	Arjan van de Ven <arjan@...ux.intel.com>,
	Peter Zijlstra <peterz@...radead.org>,
	"mingo@...nel.org" <mingo@...nel.org>,
	"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
	"preeti@...ux.vnet.ibm.com" <preeti@...ux.vnet.ibm.com>,
	"alex.shi@...el.com" <alex.shi@...el.com>,
	"efault@....de" <efault@....de>, "pjt@...gle.com" <pjt@...gle.com>,
	"len.brown@...el.com" <len.brown@...el.com>,
	"corbet@....net" <corbet@....net>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>
Subject: Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On Wed, Jul 17, 2013 at 03:14:26PM +0100, Catalin Marinas wrote:
> On Tue, Jul 16, 2013 at 04:23:08PM +0100, Arjan van de Ven wrote:
> > On 7/16/2013 5:42 AM, Catalin Marinas wrote:
> > > Morten's power scheduler tries to address the above and it will grow
> > > into controlling a new model of power driver (and taking into account
> > > Arjan's and others' comments regarding the API). At the same time, we
> > > need some form of task packing. The power scheduler can drive this
> > > (currently via cpu_power) or can simply turn a knob if there are better
> > > options that will be accepted in the scheduler.
> > 
> > how much would you be helped if there was a simple switch
> > 
> > sort left   versus    sort right
> > 
> > (assuming the big cores are all either low or high numbers)
> 
> It helps a bit compared to the current behaviour but there is a lot of
> room for improvement.
> 
> > the sorting is mostly statistical, but that's good enough in practice..
> > each time a task wakes up, you get a bias towards either low or high
> > numbered idle cpus
> 
> If cores within a cluster (socket) are not power-gated individually
> (implementation dependent), it makes more sense to spread the tasks
> among the cores to either get a lower frequency or just get to idle
> quicker. For little cores, even when they are individually power-gated,
> they don't consume much so we would rather spread the tasks equally.
> 
> > very quickly all tasks will be on one side, unless your system is so
> > loaded that all cpus are full.
> 
> It should be more like left socket vs both sockets with the possibility
> of different balancing within a socket. But then we get back to the
> sched_smt/sched_mc power aware scheduling that was removed from the
> kernel.
> 
> It's also important when to make this decision to sort left vs right and
> we want to avoid migrating threads unnecessarily. There could be small
> threads (e.g. an mp3 decoding thread) that should stay on the little
> core.

Given that the power topology is taken into account, a sort
left/right-like mechanism would only help performance insensitive tasks
on big.LITTLE. Performance sensitive tasks that each can use more than
a little cpu should move in the opposite direction. Well, directly to a
big cpu, even if some little cpus are idle.

It can be discussed whether smaller performance sensitive tasks that
would fit on a little cpu should be put on a little or big cpu. That
would depend on the nature of the task and if other tasks depend on it.


--
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/