lkml.org 
[lkml]   [2017]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2] sched/fair: update scale invariance of PELT
On Tue, Apr 11, 2017 at 09:52:21AM +0200, Vincent Guittot wrote:

> > Secondly, what's up with the util_sum < LOAD_AVG_MAX * 1000 thing?
>
> The lost idle time makes sense only if the task can also be "idle"
> when running at max capacity. When util_sum reaches the
> LOAD_AVG_MAX*SCHED_CAPACITY_SCALE value, all tasks are considered to
> be the same as we can't make any difference between a task running
> 400ms or a task running 400sec. It means that these tasks are "always
> running" tasks even at max capacity. In this case, there is no lost
> idle time as they always run and tracking and adding back the lost
> idle time because we run at lower capacity doesn't make sense anymore
> so we discard it.

Right, this is the point we reached yesterday with the too low F. At
that point you cannot know and we assuming u=1, F<1 -> u=1, F=1, which
is a sensible assumption.

> Then an always running task can have a util_sum that is less than the
> max value because of the rounding (util_avg varies between
> [1006..1023]), so I use LOAD_AVG_MAX*1000 instead of LOAD_AVG_MAX*1024

OK, so the reason util_avg varies is because we compute it wrong. And I
think we can easily fix that once we pull out all the factors (which
would mean your patch and the pulling out of weight patch which still
needs to be finished).

But you're comparing against util_sum here, that behaves slightly
different. I think you want 'util_sum >= 1024 * (LOAD_AVG_MAX - 1024)'
instead.

\
 
 \ /
  Last update: 2017-04-13 15:40    [W:0.104 / U:0.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site