scx_rustland: per-task cpumask generation counter #133
Conversation
This file contains 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
htejun
approved these changes
Feb 10, 2024
| return; | ||
|
|
||
| /* Read current cpumask generation counter */ | ||
| curr_cpumask_cnt = __sync_fetch_and_add(&tctx->cpumask_cnt, 0); |
There was a problem hiding this comment.
nit: I don't think __sync op is necessary here, curr_cpumask_cnt = tctx->cpumask should be sufficient. All the involved operations are already fully synchronized.
| tctx = lookup_task_ctx(p); | ||
| if (!tctx) | ||
| return; | ||
| task->cpumask_cnt = __sync_fetch_and_add(&tctx->cpumask_cnt, 0); |
| tctx = lookup_task_ctx(p); | ||
| if (!tctx) | ||
| return; | ||
| __sync_fetch_and_add(&tctx->cpumask_cnt, 1); |
There was a problem hiding this comment.
And this can just be tctx->cpumask_cnt++.
Introduce a per-task generation counter to check the validity of the cpumask at dispatch time. The logic is the following: - the cpumask generation number is incremented every time a task calls .set_cpumask() - when a task is enqueued the current generation number is stored in the queued_task_ctx and relayed to the user-space scheduler - the user-space scheduler can decide to dispatch the task on the CPU determined by the BPF layer in .select_cpu(), redirect the task to any other specific CPU, or redirect to the first CPU available (using NO_CPU) - task is then dispatched back to the BPF code along with its cpumask generation counter - at dispatch time the BPF code checks if the generation number is the same and it discards the dispatch attempt if the cpumask is not valid anymore (the task will be automatically re-enqueued by the sched-ext core code, potentially selecting another CPU / cpumask) - if the cpumask is valid, but the CPU selected by the user-space scheduler is invalid (according to the cpumask), the task will be transparently bounced by the BPF code to the shared DSQ (in this way the user-space code can be completely abstracted and dispatches that target invalid CPUs can be automatically fixed by the BPF layer) This solution can prevent stalls due to dispatches targeting invalid CPUs and it can also avoid redundant dispatch events, making the code more efficient and the cpumask interlocking more reliable. Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
arighi
force-pushed
the
rustland-cpumask-gen-cnt
branch
from
7d5efa6
to
61d1ed3
Compare
Updated (you're right, we don't need _sync_fetch*(), the cpumask counter is per task and it's all synchronized already). And yes, the next step will be to expose the cpumask to the user-space so that the scheduler can make better decisions (and at that point we could even make the auto-bounce to the shared DSQ logic optional with a flag or similar). Thanks for the review! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Introduce a per-task generation counter to check the validity of the cpumask at dispatch time.
The logic is the following:
the cpumask generation number is incremented every time a task calls .set_cpumask()
when a task is enqueued the current generation number is stored in the queued_task_ctx and relayed to the user-space scheduler
the user-space scheduler can decide to dispatch the task on the CPU determined by the BPF layer in .select_cpu(), redirect the task to any other specific CPU, or redirect to the first CPU available (using NO_CPU)
task is then dispatched back to the BPF code along with its cpumask generation counter
at dispatch time the BPF code checks if the generation number is the same and it discards the dispatch attempt if the cpumask is not valid anymore (the task will be automatically re-enqueued by the sched-ext core code, potentially selecting another CPU / cpumask)
if the cpumask is valid, but the CPU selected by the user-space scheduler is invalid (according to the cpumask), the task will be transparently bounced by the BPF code to the shared DSQ (in this way the user-space code can be completely abstracted and dispatches that target invalid CPUs can be automatically fixed by the BPF layer)
This solution can prevent stalls due to dispatches targeting invalid CPUs and it can also avoid redundant dispatch events, making the code more efficient and the cpumask interlocking more reliable.