topology-aware: initial scheduling class support. #626
Conversation
Signed-off-by: Antti Kervinen <[email protected]>
Signed-off-by: Antti Kervinen <[email protected]>
Signed-off-by: Antti Kervinen <[email protected]>
Signed-off-by: Antti Kervinen <[email protected]>
Signed-off-by: Antti Kervinen <[email protected]>
Signed-off-by: Antti Kervinen <[email protected]>
Add support for declaring known scheduling classes for the topology- aware policy. A scheduling class is a combination of Linux schduler policy and I/O priority parameters. It is represented using the same policy-agnostic data structure as used by the balloons policy. Signed-off-by: Krisztian Litkey <[email protected]>
Implement support for annotated assignment of containers to scheduling classes. Signed-off-by: Krisztian Litkey <[email protected]>
Signed-off-by: Krisztian Litkey <[email protected]>
Signed-off-by: Krisztian Litkey <[email protected]>
klihub
force-pushed
the
devel/topology-aware/scheduling-classes
branch
from
091fe49 to
be49f4e
Compare
klihub
changed the title
| to ionice(1) documentation for valid values. | ||
| These attributes are applied to containers which get assigned to the | ||
| class. Use the `scheduling-class.resource-policy.nri.io` annotation | ||
| key to annotate a pod or a container to a class. Currently scheduling |
There was a problem hiding this comment.
Including Burstable and BestEffort containers could have additional benefits.
Guaranteed containers with exclusive CPUs have no kernel scheduling level competition on using CPU time, so they probably benefit most from I/O priority and realtime scheduling policy for faster wakeups.
On the other hand, separate scheduling classes would help prioritizing a responsive (online request-handling) Burstable container over an offline AI-agent Burstable, that would be fine using idle CPU cycles. Because these Burstables may run using the same CPU pool, scheduling policy and priority makes a difference.
| if sc := p.getSchedulingClass(name); sc == nil { | ||
| log.Errorf("%s: unknown scheduling class %q", container.PrettyName(), name) | ||
| } else { | ||
| if grant.SharedPortion() > 0 { |
There was a problem hiding this comment.
...as in previous comment, I might have applied annotated scheduling class without any hesitation. But that's because I'm always eager giving a gun to the user who asks it, not because it would necessarily be wise. You probably have good reasons, like we don't want realtime BestEffort workloads to eat all available CPUs...
askervin
left a comment
askervin
left a comment
There was a problem hiding this comment.
Looks very good to me. I trust your judgement in the only thing that I noticed and raised reviewing this.
2 participants
Notes: This PR is stacked on top of #618.
This patch series implements initial scheduling class support for the topology-aware policy. In particular, the PR