Re: [peterz-queue:sched/eevdf] [sched/fair] 23669fce72: aim7.jobs-per-min -18.6% regression

[Peter Zijlstra <peterz@infradead.org>]

On Mon, Mar 27, 2023 at 09:51:33PM +0800, Chen Yu wrote:
> On 2023-03-26 at 13:00:24 +0200, Peter Zijlstra wrote:

> > That is, the parent is always running, while the child is blocking.
> > Consider the parent 100% running and the child 50%, then a truely fair
> > scheduler will make it 67% vs 33% runtime -- this is what EEVDF does
> > now. And as you can see, since the child gets less runtime, the counter
> > increases less and the benchmark drops.
> >
> Does the 67% vs 33% comes from the lag placement but not from
> the deadline pick policy?  Because the 'lag' remains consistent during
> task migration across several CPUs. So no matter how long the task sleeps,
> it only gets the time slice it deserved to run after migation and gets no
> sleep bonus?

Yeah, the 67%/33% thing is not due to the deadlines, it really is just
the virtual time thing -- we could make CFS do that too. 

But the bonus placement does wreck the deadline part :/

Much of these patches is more than 10 years old, back then I didn't
think I'd get away with the added 64bit math and the augmented rb tree
(we still cared about 32bit performance and all that). Perhaps I should
have spend more time finishing it back then, alas..

> > CFS has sleeper bonus, which gives (short) blocking tasks a small
> > advantage to make it 50% vs 50%. And if you compute the drop from 50% to
> > 33% then you get -33% and that's exactly the drop you see around the
> > 100% case.
> It seems that EEVDF is actually the real 'CFS' : )

Yeah, the 'completely' part of the name never made much sense to me, but
alas. Note that even EEVDF is known deficient in a number of cases,
particularly SMP, our load-balancer leaves a number of things to be
desired.

It's all a cost/performance tradeoff I suppose.