| From: |
| Mel Gorman <mgorman-AT-techsingularity.net> |
| To: |
| linux-kernel-AT-vger.kernel.org |
| Subject: |
| [RFC PATCH 0/2] Reintroduce NEXT_BUDDY for EEVDF v2 |
| Date: |
| Tue, 21 Oct 2025 15:28:22 +0100 |
| Message-ID: |
| <20251021142824.3747201-1-mgorman@techsingularity.net> |
| Cc: |
| Peter Zijlstra <peterz-AT-infradead.org>, 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>, Mel Gorman <mgorman-AT-techsingularity.net> |
| Archive-link: |
| Article |
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 RFC is to determine if this is valid approach to prefer selecting
a wakee if it's eligible to run even though other unrelated tasks are
more eligible.
kernel/sched/fair.c | 131 ++++++++++++++++++++++++++++++++++------
kernel/sched/features.h | 2 +-
2 files changed, 112 insertions(+), 21 deletions(-)
--
2.51.0
