[Deepin-Kernel-SIG] [linux 6.6-y] [Upstream] sched/fair: Forfeit vruntime on yield #1395
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
stable inclusion from stable-v6.12.63 category: bugfix [ Upstream commit 79104becf42baeeb4a3f2b106f954b9fc7c10a3c ] 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: 147f3ef ("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 Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit d5843e1530d8d4ebf2b34f0185d45828848f107a) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Reviewer's guide (collapsed on small PRs)Reviewer's GuidePorts the upstream fix for CFS yield behavior so that yielding tasks forfeit remaining vruntime and advance deadline only when eligible, preventing runaway deadlines and anomalous scheduling delays under EEVDF-like scheduling. Sequence diagram for CFS yield loop preventionsequenceDiagram
actor Task
participant Scheduler
participant CFSRunQueue as CFS_run_queue
participant SchedEntity as Sched_entity
Task->>Scheduler: sys_sched_yield
Scheduler->>CFSRunQueue: lock_rq_and_skip_clock_update
Scheduler->>SchedEntity: yield_task_fair
SchedEntity->>CFSRunQueue: entity_eligible cfs_rq se ?
alt entity is not eligible
SchedEntity-->>Scheduler: no_vruntime_change
else entity is eligible
SchedEntity->>SchedEntity: se_vruntime = se_deadline
SchedEntity->>SchedEntity: se_deadline += calc_delta_fair se_slice se
SchedEntity->>CFSRunQueue: update_min_vruntime cfs_rq
SchedEntity-->>Scheduler: vruntime_forfeited_and_deadline_advanced
end
Scheduler->>Scheduler: select_next_entity_to_run
Scheduler-->>Task: may_or_may_not_pick_same_task_based_on_new_deadline
Flow diagram for updated yield_task_fair behaviorflowchart TD
A[rq_lock_acquired_and_rq_clock_skip_update] --> B[call_yield_task_fair]
B --> C[entity_eligible cfs_rq se ?]
C -->|no| D[skip_vruntime_forfeit_and_deadline_update]
D --> E[return_from_yield_task_fair]
C -->|yes| F[set se_vruntime_to_se_deadline]
F --> G[advance_se_deadline_by_calc_delta_fair se_slice se]
G --> H[update_min_vruntime cfs_rq]
H --> E[return_from_yield_task_fair]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
deepin pr auto review我来对这个代码变更进行详细分析：
这个修改主要解决了在core调度场景下可能出现的问题，通过添加条件检查和适当的vruntime更新机制，提高了系统的稳定性和公平性。修改是合理且必要的。 |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've left some high level feedback:
- Consider expanding the commit message or in-code comment to clarify why skipping the deadline update entirely for ineligible entities is correct (i.e., why we don't need to advance their deadline at all on yield), since that subtlety is easy to misinterpret when reasoning about fairness.
- It may be worth mentioning in the comment what happens to
se->vruntimewhenentity_eligible()is false (i.e., that we intentionally keep both vruntime and deadline unchanged) to make the behavior in core-sched scenarios more explicit for future readers.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Consider expanding the commit message or in-code comment to clarify why skipping the deadline update entirely for ineligible entities is correct (i.e., why we don't need to advance their deadline at all on yield), since that subtlety is easy to misinterpret when reasoning about fairness.
- It may be worth mentioning in the comment what happens to `se->vruntime` when `entity_eligible()` is false (i.e., that we intentionally keep both vruntime and deadline unchanged) to make the behavior in core-sched scenarios more explicit for future readers.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Member
|
/approve |
There was a problem hiding this comment.
Pull request overview
This PR backports an upstream scheduler fix that prevents virtual runtime (vruntime) runaway when tasks repeatedly yield. The fix makes yielding tasks forfeit their remaining vruntime and advance their deadline, but only when the task is eligible, preventing a yield loop scenario in core scheduling configurations.
- Adds eligibility check before vruntime forfeiture to prevent yield loops
- Updates vruntime to deadline and advances deadline by one slice for eligible tasks
- Updates min_vruntime after modifying the current task's vruntime
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Avenger-285714 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
stable inclusion
from stable-v6.12.63
category: bugfix
[ Upstream commit 79104becf42baeeb4a3f2b106f954b9fc7c10a3c ]
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: 147f3ef ("sched/fair: Implement an EEVDF-like scheduling policy")
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
(cherry picked from commit d5843e1530d8d4ebf2b34f0185d45828848f107a)
Summary by Sourcery
Bug Fixes: