| From: |
| Mel Gorman <mgorman-AT-techsingularity.net> |
| To: |
| Peter Zijlstra <peterz-AT-infradead.org> |
| Subject: |
| [PATCH 0/2 v4] Reintroduce NEXT_BUDDY for EEVDF |
| Date: |
| Mon, 03 Nov 2025 11:04:43 +0000 |
| Message-ID: |
| <20251103110445.3503887-1-mgorman@techsingularity.net> |
| Cc: |
| Ingo Molnar <mingo-AT-redhat.com>, Juri Lelli <juri.lelli-AT-redhat.com>, Dietmar Eggemann <dietmar.eggemann-AT-arm.com>, Valentin Schneider <vschneid-AT-redhat.com>, Chris Mason <clm-AT-meta.com>, linux-kernel-AT-vger.kernel.org, Mel Gorman <mgorman-AT-techsingularity.net> |
| Archive-link: |
| Article |
Changes since v3
o Place new code near first consumer (peterz)
o Separate between PREEMPT_SHORT and NEXT_BUDDY (peterz)
o Naming and code flow clarity (peterz)
o Restore slice protection (peterz)
Changes since v2
o Review feedback applied from Prateek
I've been chasing down a number of schedule issues recently like many
others and found they were broadly grouped as
1. Failure to boost CPU frequency with powersave/ondemand governors
2. Processors entering idle states that are too deep
3. Differences in wakeup latencies for wakeup-intensive workloads
Adding topology into account means that there is a lot of machine-specific
behaviour which may explain why some discussions recently have reproduction
problems. Nevertheless, the removal of LAST_BUDDY and NEXT_BUDDY being
disabled has an impact on wakeup latencies.
This series enables NEXT_BUDDY and may select a wakee if it's eligible to
run even though other unrelated tasks may have an earlier deadline.
kernel/sched/fair.c | 145 ++++++++++++++++++++++++++++++++++------
kernel/sched/features.h | 2 +-
2 files changed, 124 insertions(+), 23 deletions(-)
--
2.51.0
