sched/fair: Untangle NEXT_BUDDY and pick_next_task()
authorPeter Zijlstra <peterz@infradead.org>
Fri, 29 Nov 2024 10:15:41 +0000 (11:15 +0100)
committerPeter Zijlstra <peterz@infradead.org>
Mon, 9 Dec 2024 10:48:13 +0000 (11:48 +0100)
There are 3 sites using set_next_buddy() and only one is conditional
on NEXT_BUDDY, the other two sites are unconditional; to note:

  - yield_to_task()
  - cgroup dequeue / pick optimization

However, having NEXT_BUDDY control both the wakeup-preemption and the
picking side of things means its near useless.

Fixes: 147f3efaa241 ("sched/fair: Implement an EEVDF-like scheduling policy")
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20241129101541.GA33464@noisy.programming.kicks-ass.net
kernel/sched/fair.c
kernel/sched/features.h

index b505d3dba2c84e724e6e3b66de286070b2a8aaf0..2c4ebfc8291761c009dcaa0cef5e80daaeb572bc 100644 (file)
@@ -5630,9 +5630,9 @@ pick_next_entity(struct rq *rq, struct cfs_rq *cfs_rq)
        struct sched_entity *se;
 
        /*
-        * Enabling NEXT_BUDDY will affect latency but not fairness.
+        * Picking the ->next buddy will affect latency but not fairness.
         */
-       if (sched_feat(NEXT_BUDDY) &&
+       if (sched_feat(PICK_BUDDY) &&
            cfs_rq->next && entity_eligible(cfs_rq, cfs_rq->next)) {
                /* ->next will never be delayed */
                SCHED_WARN_ON(cfs_rq->next->sched_delayed);
index a3d331dd2d8ff4de61acab0956be050f2a72038e..3c12d9f93331d6eb387c5a73f308cb648f4385b2 100644 (file)
@@ -31,6 +31,15 @@ SCHED_FEAT(PREEMPT_SHORT, true)
  */
 SCHED_FEAT(NEXT_BUDDY, false)
 
+/*
+ * Allow completely ignoring cfs_rq->next; which can be set from various
+ * places:
+ *   - NEXT_BUDDY (wakeup preemption)
+ *   - yield_to_task()
+ *   - cgroup dequeue / pick
+ */
+SCHED_FEAT(PICK_BUDDY, true)
+
 /*
  * Consider buddies to be cache hot, decreases the likeliness of a
  * cache buddy being migrated away, increases cache locality.