lkml.org 
[lkml]   [2017]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [RFC][PATCH] sched: attach extra runtime to the right avg
* josef@toxicpanda.com <josef@toxicpanda.com> wrote:

> From: Josef Bacik <jbacik@fb.com>
>
> We only track the load avg of a se in 1024 ns chunks, so in order to
> make up for the loss of the < 1024 ns part of a run/sleep delta we only
> add the time we processed to the se->avg.last_update_time. The problem
> is there is no way to know if this extra time was while we were asleep
> or while we were running. Instead keep track of the remainder and apply
> it in the appropriate place. If the remainder was while we were
> running, add it to the delta the next time we update the load avg while
> running, and the same for sleeping. This (coupled with other fixes)
> mostly fixes the regression to my workload introduced by Peter's
> experimental runnable load propagation patches.
>
> Signed-off-by: Josef Bacik <jbacik@fb.com>

> @@ -2897,12 +2904,16 @@ ___update_load_avg(u64 now, int cpu, struct sched_avg *sa,
> * Use 1024ns as the unit of measurement since it's a reasonable
> * approximation of 1us and fast to compute.
> */
> + remainder = delta & (1023UL);
> + sa->last_update_time = now;
> + if (running)
> + sa->run_remainder = remainder;
> + else
> + sa->sleep_remainder = remainder;
> delta >>= 10;
> if (!delta)
> return 0;
>
> - sa->last_update_time += delta << 10;
> -

So I'm wondering, this chunk changes how sa->last_update_time is maintained in
___update_load_avg(): the new code takes a precise timestamp, but the old code was
not taking an imprecise timestamp, but was updating it via deltas - where each
delta was rounded down to the nearest 1024 nsecs boundary.

That, if this is the main code path that updates ->last_update_time, creates a
constant drift of rounding error that skews ->last_update_time into larger and
larger distances from the real 'now' - ever increasing the value of 'delta'.

An intermediate approach to improve that skew would be something like below. It
doesn't track the remainder like your patch does, but doesn't lose precision
either, just rounds down 'now' to the nearest 1024 boundary.

Does this fix the regression you observed as well? Totally untested.

Thanks,

Ingo

kernel/sched/fair.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 008c514dc241..b03703cd7989 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2965,7 +2965,7 @@ ___update_load_avg(u64 now, int cpu, struct sched_avg *sa,
if (!delta)
return 0;

- sa->last_update_time += delta << 10;
+ sa->last_update_time = now & ~1023ULL;

/*
* Now we know we crossed measurement unit boundaries. The *_avg
\
 
 \ /
  Last update: 2017-07-02 19:27    [W:0.287 / U:40.760 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site