Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1610762 > unrolled thread

Re: [RESEND PATCH 2/2] sched/fair: Optimize __update_sched_avg()

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RESEND PATCH 2/2] sched/fair: Optimize __update_sched_avg() Peter Zijlstra <peterz@infradead.org> - 2017-03-28 15:00 +0200
    Re: [RESEND PATCH 2/2] sched/fair: Optimize __update_sched_avg() Yuyang Du <yuyang.du@intel.com> - 2017-03-29 10:10 +0200

#1610762 — Re: [RESEND PATCH 2/2] sched/fair: Optimize __update_sched_avg()

This Changelog being so impenetrable is what makes me skip over it;
I'll put it on the 'look-at-later' pile, and that just never happens :/

On Mon, Feb 13, 2017 at 05:44:23AM +0800, Yuyang Du wrote:
> __update_load_avg() has the following steps:
> 
>   1. add the remainder of the last incomplete period
>   2. decay old sum
>   3. accumulate new sum in full periods since last_update_time
>   4. accumulate the current incomplete period
>   5. update averages
> 
> However, there is no need to separately compute steps 1, 3, and 4.
> 
> Illustation:
> 
>              c1          c3           c4
>              ^           ^            ^
>              |           |            |
>            |<->|<----------------->|<--->|
>    ... |---x---|------| ... |------|-----x (now)
> 
> c1, c3, and c4 are the accumulated (meanwhile decayed) contributions
> in timing in steps 1, 3, and 4 respectively.
> 
> With them, the accumulated contribution to load_sum, for example, is:
> 
> contrib = c1 * weight * freq_scaled;
> contrib += c3 * weight * freq_scaled;
> contrib += c4 * weight * freq_scaled;
> 
> Obviously, we can optimize the above and they equate to:
> 
> contrib = c1 + c3 + c4;
> contrib *= weight * freq_scaled;

But that's not at all what's happening;

The equation is something like:

                       1 (p+1)/32            p+1 1 n/32
 load = (load' + c1) * -^          + 1024 * \Sum -^     + c4
                       2                     n=1 2

                                     <---------------->
				            c3


And then its 'obvious' you cannot do c1+c3+c4 anything.


The decay factor of each part (c1,c3,4) is different, so unless you
explain how that works, instead of hand-wave a bit, this isn't making
any sense.

[toc] | [next] | [standalone]

#1611674

On Tue, Mar 28, 2017 at 02:50:22PM +0200, Peter Zijlstra wrote:
> This Changelog being so impenetrable is what makes me skip over it;
> I'll put it on the 'look-at-later' pile, and that just never happens :/
 
Very understandable, but thank you. I hope I can write the changelog
better. :)

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web