lkml.org 
[lkml]   [2016]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 07/13] sched/fair: Let asymmetric cpu configurations balance at wake-up
On Thu, Jul 14, 2016 at 03:45:17PM +0200, Vincent Guittot wrote:
> On 13 July 2016 at 18:14, Morten Rasmussen <morten.rasmussen@arm.com> wrote:
> > On Wed, Jul 13, 2016 at 02:56:41PM +0200, Vincent Guittot wrote:
> >> On 22 June 2016 at 19:03, Morten Rasmussen <morten.rasmussen@arm.com> wrote:
> >> > Currently, SD_WAKE_AFFINE always takes priority over wakeup balancing if
> >> > SD_BALANCE_WAKE is set on the sched_domains. For asymmetric
> >> > configurations SD_WAKE_AFFINE is only desirable if the waking task's
> >> > compute demand (utilization) is suitable for all the cpu capacities
> >> > available within the SD_WAKE_AFFINE sched_domain. If not, let wakeup
> >>
> >> instead of "suitable for all the cpu capacities available within the
> >> SD_WAKE_AFFINE sched_domain", should it be "suitable for local cpu and
> >> prev cpu" becasue you only check the capacity of these 2 CPUs.
> >
> > Good point. I currently make the implicit assumption that capacity of local cpu
> > and prev cpu represent the capacity for all cpus their SD_WAKE_AFFINE
> > domains. It breaks if you should choose to have SD_WAKE_AFFINE on a
> > domain that spans both little and big cpus, as if local/prev cpu happens
> > to be big we assume that they are all big and let select_idle_sibling()
> > handle the task placement even for big tasks if local/prev cpu are both
> > big.
>
> Isn't the sd_llc used in select_idle_sibling and not the
> SD_WAKE_AFFINE domian so if CPUs in the sd_llc are homogeneous, we are
> safe

Yes, I confused myself (again) with SD_WAKE_AFFINE and sd_llc in the
above. It should have been sd_llc instead of SD_WAKE_AFFINE. I will fix
the commit message to be correct.

\
 
 \ /
  Last update: 2016-07-15 11:21    [W:0.150 / U:0.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site