From 865c37f6224fe7917c6db95984f921a07c611bf7 Mon Sep 17 00:00:00 2001 From: LFRon Date: Fri, 7 Aug 2026 19:12:06 +0800 Subject: [PATCH] 6.18: bore-cachy: port check_preempt_wakeup_fair to the 6.18.42 scheduler rework The BORE 6.6.3 patch failed to apply on 6.18.42. Only one hunk broke: Hunk #23 in kernel/sched/fair.c, because check_preempt_wakeup_fair() was substantially reworked upstream and none of its context lines exist anymore: - __pick_eevdf(cfs_rq, !do_preempt_short) was replaced by pick_next_entity() + "if (nse == pse) goto preempt;" - the do_preempt_short boolean was replaced by the preempt_wakeup_action enum (PREEMPT_WAKEUP_SHORT/PICK/...) - an extra "!nse && cfs_rq->nr_queued" re-pick block was inserted before the RUN_TO_PARITY protect path Adapt the hunk to the new structure while preserving BORE semantics: insert the penalty-based short-preempt right after "if (nse == pse) goto preempt;" (the structural equivalent of the old "if (__pick_eevdf(...) == pse) goto preempt;" spot) and map the trigger do_preempt_short = true; goto preempt; to the new short-preempt equivalent preempt_action = PREEMPT_WAKEUP_SHORT; goto preempt; which the preempt: label handles as cancel_protect_slice(se) + resched_curr_lazy(rq) -- exactly the old short-preempt behaviour. The BORE condition itself (sched_bore_key + PREEMPT_SHORT_BORE + both entities are tasks + waker penalty < current penalty) is unchanged. No kernel-original control flow is altered: on the non-BORE path the !nse re-pick and RUN_TO_PARITY protect logic remain intact. The remaining 24 hunks are untouched (byte-identical). The full patch now applies cleanly to 6.18.42 with zero fuzz and zero rejects (verified with `patch -p1 --dry-run -F0`). --- 6.18/sched/0001-bore-cachy.patch | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/6.18/sched/0001-bore-cachy.patch b/6.18/sched/0001-bore-cachy.patch index e008fc6c..eca73b5e 100644 --- a/6.18/sched/0001-bore-cachy.patch +++ b/6.18/sched/0001-bore-cachy.patch @@ -1196,8 +1196,8 @@ index b2e4fd2070c4..6f3360a6c8ce 100644 if (dequeue_entities(rq, &p->se, flags) < 0) return false; -@@ -8893,6 +8960,16 @@ static void check_preempt_wakeup_fair(struct rq *rq, struct task_struct *p, int - if (__pick_eevdf(cfs_rq, !do_preempt_short) == pse) +@@ -8988,6 +8988,16 @@ + if (nse == pse) goto preempt; +#ifdef CONFIG_SCHED_BORE @@ -1205,14 +1205,14 @@ index b2e4fd2070c4..6f3360a6c8ce 100644 + sched_feat(PREEMPT_SHORT_BORE) && + entity_is_task(pse) && entity_is_task(se) && + task_of(pse)->bore.penalty < task_of(se)->bore.penalty) { -+ do_preempt_short = true; ++ preempt_action = PREEMPT_WAKEUP_SHORT; + goto preempt; + } +#endif /* CONFIG_SCHED_BORE */ + - if (sched_feat(RUN_TO_PARITY) && do_preempt_short) - update_protect_slice(cfs_rq, se); - + /* + * Because p is enqueued, nse being null can only mean that we + * dequeued a delayed task. If there are still entities queued in @@ -9067,16 +9144,25 @@ static void yield_task_fair(struct rq *rq) /* * Are we the only task in the tree?