On Fri, Dec 15, 2017 at 12:14:17PM +0000, Patrick Bellasi wrote:
> On 13-Dec 17:16, Peter Zijlstra wrote:
> > > + /*
> > > + * Skip update of task's estimated utilization when its EWMA is already
> > > + * ~1% close to its last activation value.
> > > + */
> > > + util_est = p->util_est.ewma;
> > > + if (abs(util_est - util_last) <= (SCHED_CAPACITY_SCALE / 100))
> > > + return;
> >
> > Isn't that computation almost as expensive as the stuff you're trying to
> > avoid?
>
> Mmm... maybe slightly simpler. I'll profile it again but I remember
> I've added it because it was slightly better on backbench.
>
> This code at the end it's just a "sub" and a "compare to constant" and
> it's likely to bail early for all "almost regular" tasks.
>
> Are you worried about the branch overhead?
Its a subtract, a test for sign, a conditional branch on test, a negate,
a subtract constant and another conditinoal branch.
Branch overhead certainly matters too.
> > > + p->util_est.last = util_last;
> > > + ewma = p->util_est.ewma;
> > > + if (likely(ewma != 0)) {
> >
> > Why special case 0? Yes it helps with the initial ramp-on, but would not
> > an asymmetric IIR (with a consistent upward bias) be better?
>
> Yes, maybe the fast ramp-up is not really necessary... I'll test it
> without on some real use-cases and see if we really get any noticiable
> benefit, otheriwse I'll remove it.
>
> Thanks for pointing this out.
>
> > > + ewma = util_last + (ewma << UTIL_EST_WEIGHT_SHIFT) - ewma;
> > > + ewma >>= UTIL_EST_WEIGHT_SHIFT;
> > > + } else {
> > > + ewma = util_last;
> > > + }
> > > + p->util_est.ewma = ewma;
And this, without the 0 case, is shift, an add, a subtract and another
shift followed by a store.
Which is less branches and roughly similar arith ops, some of which can
be done in parallel.
I suspect what you saw on the profile is the cacheline hit of the store,
but I'm not sure.
