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

Date:	Thu, 25 Jul 2013 09:00:13 +0100
From:	Morten Rasmussen <morten.rasmussen@....com>
To:	Arjan van de Ven <arjan@...ux.intel.com>
Cc:	Catalin Marinas <Catalin.Marinas@....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 24, 2013 at 05:48:42PM +0100, Arjan van de Ven wrote:
> >
> > I would expect performance to be disjoint for most tasks. If there was
> > an overlap, the big would probably be less power efficient (as in
> > energy/instruction) than the little so you would prefer to run on the
> > little anyway.
> >
> > In what way would you use the overlap?
> 
> if the scheduler thinks a task would be better off on the other side
> than where it is now, it could first move it into the "overlap area" on the
> same side by means of experiment, and if the task behaves as expected there,
> THEN move it over.

You could do that, but due to the different uarchs you wouldn't really
know how a cpu bound task would behave on the other side. It would
probably work for memory bound tasks.

Also, for interactive applications (smartphones and such) intermediate
steps will increase latency when going little to big. Going the other
way it would be fine.

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