[PATCH 0/2 v5] Reintroduce NEXT_BUDDY for EEVDF

[Mel Gorman <mgorman@techsingularity.net>]

Changes since v4
o Splitout decisions into separate functions			(peterz)
o Flow clarity							(peterz)

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.

Mel Gorman (2):
  sched/fair: Enable scheduler feature NEXT_BUDDY
  sched/fair: Reimplement NEXT_BUDDY to align with EEVDF goals

 kernel/sched/fair.c     | 152 ++++++++++++++++++++++++++++++++++------
 kernel/sched/features.h |   2 +-
 2 files changed, 131 insertions(+), 23 deletions(-)

-- 
2.51.0