summaryrefslogtreecommitdiff
path: root/scripts/basic
diff options
context:
space:
mode:
authorFernand Sieber <sieberf@amazon.com>2025-09-18 18:05:28 +0300
committerPeter Zijlstra <peterz@infradead.org>2025-10-16 12:13:49 +0300
commit79104becf42baeeb4a3f2b106f954b9fc7c10a3c (patch)
treedd704c17ad4e81f89d77142b117db96dd9137236 /scripts/basic
parent3a8660878839faadb4f1a6dd72c3179c1df56787 (diff)
downloadlinux-79104becf42baeeb4a3f2b106f954b9fc7c10a3c.tar.xz
sched/fair: Forfeit vruntime on yield
If a task yields, the scheduler may decide to pick it again. The task in turn may decide to yield immediately or shortly after, leading to a tight loop of yields. If there's another runnable task as this point, the deadline will be increased by the slice at each loop. This can cause the deadline to runaway pretty quickly, and subsequent elevated run delays later on as the task doesn't get picked again. The reason the scheduler can pick the same task again and again despite its deadline increasing is because it may be the only eligible task at that point. Fix this by making the task forfeiting its remaining vruntime and pushing the deadline one slice ahead. This implements yield behavior more authentically. We limit the forfeiting to eligible tasks. This is because core scheduling prefers running ineligible tasks rather than force idling. As such, without the condition, we can end up on a yield loop which makes the vruntime increase rapidly, leading to anomalous run delays later down the line. Fixes: 147f3efaa24182 ("sched/fair: Implement an EEVDF-like scheduling policy") Signed-off-by: Fernand Sieber <sieberf@amazon.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20250401123622.584018-1-sieberf@amazon.com Link: https://lore.kernel.org/r/20250911095113.203439-1-sieberf@amazon.com Link: https://lore.kernel.org/r/20250916140228.452231-1-sieberf@amazon.com
Diffstat (limited to 'scripts/basic')
0 files changed, 0 insertions, 0 deletions