[PATCH 0/2] sched/eevdf: Fix slice protection across state changes

[Christian Loehle <christian.loehle@arm.com>]

These two fixes address slice-protection boundaries that become stale
after a request-size or weight change, found when testing a few edge
cases for Vincent's series:
https://lore.kernel.org/lkml/20260921152238.3804392-1-vincent.guittot@linaro.org/

Patch 1 caps every fresh protection grant at the selected minimum slice.
A preserved deadline can outlast a task's new, shorter request, including
when current itself owns the minimum slice. In that case the existing
slice != se->slice condition skips the cap. This completes the minimum-
slice bound from aae2a33ea662 ("sched/eevdf: Ensure that vprot will never go
above a min slice").

Patch 2 keeps expired protection expired when reweighting moves vruntime.
An old absolute vprot can otherwise become live again and cause current
to be selected over an eligible entity with an earlier deadline. Anchor
the expired boundary at the new vruntime while retaining the existing
rescaling of live protection.

For the first case a task reducing its request from 100 ms to 100 us can
receive over 26 ms of fresh protection while competing with a 1 ms task.
For the second case directed cgroup-weight changes show expired protection
becoming live and affecting selection.

Based on v7.3-rc5 plus:

  c72945693b90 sched: Restart fair hrtick after same-task repicks
  aae2a33ea662 sched/eevdf: Ensure that vprot will never go above a min slice
  4bf32ec3327d sched/eevdf: Align update_protect_slice to set_protect_slice
  d2e010082757 sched/eevdf: Handle more short slice waking cases

(Patch 2 is independent, patch 1 follows Vincent's minimum-slice change)

Thanks,
Christian

Christian Loehle (2):
  sched/eevdf: Cap protection when current has the shortest slice
  sched/eevdf: Keep expired protection expired across reweighting

 kernel/sched/fair.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)