[lkml]   [2013]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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.

 \ /
  Last update: 2013-07-24 16:21    [W:0.071 / U:2.720 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site