Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 9 Apr 2024 11:27:49 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH 5/5] sched/fair: Rename set_next_buddy() to set_next_pick() |
| |
On Tue, Apr 09, 2024 at 10:32:59AM +0200, Ingo Molnar wrote:
> I don't think we want to nuke it - there's 3 users: > > - yield() > - CFS bandwidth > - wakeup > > I think the yield() and CFS bandwidth ones are genuine, but non-working due > to NEXT_BUDDY at 0. Wakeup was the original intended NEXT_BUDDY logic, but > it got turned off due to some performance or latency considerations that > might or might not be valid & relevant today. > > 2) > > Even the task_hot() use of ->next isn't spurious: if a task has been marked > as run-next, then presumably the current task is descheduling and we should > probably not tear its ->next away in load-balancing. > > 3) > > Side note: a set rq->next should probably reduce a candidate runqueue's > weight both in periodic load-balancing and in idle-balancing, by rq->curr's > weight or so? > > So what I think we should do is to keep ->next and fix all its intended > uses, and make it all unconditional by removing both NEXT_BUDDY and > CACHE_HOT_BUDDY. I can cook up a series if you agree in principle.
So yes on fixing those yield_to() and cfs_bandwidth thingies, but put then under a new knob -- if the fix regresses we can simply flip it.
Ack on removing the current knobs, for them not having been changed in forever.
| ![\](/images/icornerr.gif) |