On Thu, 21 Mar 2024 at 13:18, Tobias Huschle <husc...@linux.ibm.com> wrote: > > On Wed, Mar 20, 2024 at 02:51:00PM +0100, Vincent Guittot wrote: > > On Wed, 20 Mar 2024 at 08:04, Tobias Huschle <husc...@linux.ibm.com> wrote: > > > 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;
and then se->vruntime = max_vruntime(se->vruntime, vruntime) > > 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.