lkml.org 
[lkml]   [2016]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v3 10/13] sched/fair: Compute task/cpu utilization at wake-up more correctly
On Fri, Aug 19, 2016 at 09:43:00AM +0800, Wanpeng Li wrote:
> 2016-08-18 21:45 GMT+08:00 Morten Rasmussen <morten.rasmussen@arm.com>:
> > I assume you are referring to using task_util_peak() instead of
> > task_util() in wake_cap()?
>
> Yes.
>
> >
> > The peak value should never exceed the util_avg accumulated by the task
> > last time it ran. So any spike has to be caused by the task accumulating
> > more utilization last time it ran. We don't know if it a spike or a more
>
> I see.
>
> > permanent change in behaviour, so we have to guess. So a spike on an
> > asymmetric system could cause us to disable wake affine in some
> > circumstances (either prev_cpu or waker cpu has to be low compute
> > capacity) for the following wake-up.
> >
> > SMP should be unaffected as we should bail out on the previous
> > condition.
>
> Why capacity_orig instead of capacity since it is checked each time
> wakeup and maybe rt class/interrupt have already occupied many cpu
> utilization.

We could switch to capacity for this condition if we also change the
spare capacity evaluation in find_idlest_group() to do the same. It
would open up for SMP systems to take find_idlest_group() route if the
SD_BALANCE_WAKE flag is set.

The reason why I have avoided capacity and used capacity_orig instead
is that in previous discussions about scheduling behaviour under
rt/dl/irq pressure it has been clear to me whether we want to move tasks
away from cpus with capacity < capacity_orig or not. The choice depends
on the use-case.

In some cases taking rt/dl/irq pressure into account is more complicated
as we don't know the capacities available in a sched_group without
iterating over all the cpus. However, I don't think it would complicate
these patches. It is more a question whether everyone are happy with
additional conditions in their wake-up path. I guess we could make it a
sched_feature if people are interested?

In short, I used capacity_orig to play it safe ;-)

> > The counter-example is task with a fairly long busy period and a much
> > longer period (cycle). Its util_avg might have decayed away since the
> > last activation so it appears very small at wake-up and we end up
> > putting it on a low capacity cpu every time even though it keeps the cpu
> > busy for a long time every time it wakes up.
>
> Agreed, that's the reason for under-estimation concern.
>
> >
> > Did that answer your question?
>
> Yeah, thanks for the clarification.

You are welcome.

\
 
 \ /
  Last update: 2016-09-17 09:57    [W:0.748 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site