-
Notifications
You must be signed in to change notification settings - Fork 148
scx_p2dq: Refactor vtime handling of migrating tasks #1833
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
*/ | ||
if ((p->flags & PF_KTHREAD) && !taskc->all_cpus && | ||
if ((p->flags & PF_KTHREAD) && p->cpus_ptr == &p->cpus_mask && p->nr_cpus_allowed == nr_cpus && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is purely to avoid looking up the task_ctx
for affinitized kthreads.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left a comment, but overall LGTM.
return; | ||
} | ||
|
||
// Give a slight boost to high priority tasks migrating across LLCs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So in case of a cross-LLC migration we reset all the accumulated vtime budget? I'm wondering if we're penalizing too much tasks that are migrating.
Have you tried for example to change just the vtime_min with this new logic?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me do some more testing on this. I was trying to avoid extra lookups of the previous llc_ctx
and use some heuristic to give the right tasks enough of a bump. Perhaps in this case is is worth doing the check though.
} | ||
|
||
// Give a slight boost to high priority tasks migrating across LLCs. | ||
if (p->scx.weight < 100) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I recall correctly, higher scx.weight
means higher priority. If so, it should be p->scx.weight > 100
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, it will be a good idea to document the idea behind this if-else
block more in detail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I recall correctly, higher
scx.weight
means higher priority. If so, it should bep->scx.weight > 100
.
Minor note: scx.weight > 100
in terms of scheduling weight.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Going to go with the simple approach and just set the set the vtime to the current llc vtime.
5e32e10
to
e8fe6b5
Compare
Refactor vtime updating into a helper method and update the enqueue method to properly update vtime after selecting a CPU. Signed-off-by: Daniel Hodges <[email protected]>
e8fe6b5
to
778f1e5
Compare
When updating the vtime of a task moving across LLCs give tasks with a lower weight a boost in vtime. Refactor vtime updating into a helper method and update the enqueue method to properly update vtime after selecting a CPU.