Re: [RFC] sched/eevdf: sched feature to dismiss lag on wakeup

On Wed, 20 Mar 2024 at 08:04, Tobias Huschle [off-list ref] wrote:

On Tue, Mar 19, 2024 at 02:41:14PM +0100, Vincent Guittot wrote:

quoted

On Tue, 19 Mar 2024 at 10:08, Tobias Huschle [off-list ref] wrote:

quoted

...

quoted

quoted

Haven't seen that one yet. Unfortunately, it does not help to ignore the
eligibility.

I'm inclined to rather propose propose a documentation change, which
describes that tasks should not rely on woken up tasks being scheduled
immediately.

Where do you see such an assumption ? Even before eevdf, there were
nothing that ensures such behavior. When using CFS (legacy or eevdf)
tasks, you can't know if the newly wakeup task will run 1st or not

There was no guarantee of course. place_entity was reducing the vruntime of
woken up tasks though, giving it a slight boost, right?. For the scenario

It was rather the opposite, It was ensuring that long sleeping tasks
will not get too much bonus because of vruntime too far in the past.
This is similar although not exactly the same intent as the lag. The
bonus was up to 24ms previously whereas it's not more than a slice now

that I observed, that boost was enough to make sure, that the woken up tasks
gets scheduled consistently. This might still not be true for all scenarios,
but in general EEVDF seems to be stricter with woken up tasks.

Dismissing the lag on wakeup also does obviously not guarantee getting
scheduled, as other tasks might still be involved.

The question would be if it should be explicitly mentioned somewhere that,
at this point, woken up tasks are not getting any special treatment and
noone should rely on that boost for woken up tasks.

quoted

quoted

Changing things in the code to address for the specific scenario I'm
seeing seems to mostly create unwanted side effects and/or would require
the definition of some magic cut-off values.

On Wed, Mar 20, 2024 at 02:51:00PM +0100, Vincent Guittot wrote:

On Wed, 20 Mar 2024 at 08:04, Tobias Huschle [off-list ref] wrote:

quoted

There was no guarantee of course. place_entity was reducing the vruntime of
woken up tasks though, giving it a slight boost, right?. For the scenario

It was rather the opposite, It was ensuring that long sleeping tasks
will not get too much bonus because of vruntime too far in the past.
This is similar although not exactly the same intent as the lag. The
bonus was up to 24ms previously whereas it's not more than a slice now

I might have gotten this quite wrong then. I was looking at place_entity
and saw that non-initial placements get their vruntime reduced via

    vruntime -= thresh;

which would mean that the placed task would have a vruntime smaller than
cfs_rq->min_vruntime, based on pre-EEVDF behavior, last seen at:

   af4cf40470c2 sched/fair: Add cfs_rq::avg_vruntime

If there was no such benefit for woken up tasks. Then the scenario I observed
is just conincidentally worse with EEVDF, which can happen when exchanging an
algorithm I suppose. Or EEVDF just exposes a so far hidden problem in that 
scenario.