-
Notifications
You must be signed in to change notification settings - Fork 135
layered container support #1747
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
base: main
Are you sure you want to change the base?
layered container support #1747
Conversation
612f186
to
64f4056
Compare
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 AFAICT The changes are:
- Machinery for forwarding cpuset information to the BPF side
- The corresponding BPF code
- Logic that replicates allow_node_aligned but for cpusets.
If this fixes cpuset related problems I think it is reasonable, but I'm not sure about the naming - contianer enable is a bit confusing because containers aren't really a thing at this level of abstraction. Maybe replace "container" with "cpuset-based workloads"? This way it's clear what the code does concretely.
!(layer->allow_node_aligned && taskc->cpus_node_aligned)) || | ||
!layer->nr_cpus) { | ||
!(layer->allow_node_aligned && taskc->cpus_node_aligned)) || | ||
!(enable_container && taskc->cpus_cpuset_aligned) || |
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.
Wrt the bug, maybe wrap lines 1354-1355 in parentheses? && has a higher precedence than || so rn all tasks without cpus_cpuset_aligned are getting put into the fallback queue regardless of the value of tasks->all_cpus_allowed.
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.
think that was it, thanks 1000x for that.
well, part of it, went from exclusively using lo fallback to largely using it.
@@ -30,6 +30,7 @@ enum consts { | |||
MAX_TASKS = 131072, | |||
MAX_PATH = 4096, | |||
MAX_NUMA_NODES = 64, | |||
MAX_CONTAINERS = 64, |
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.
Can we use cpuset
/ CPUSET
consistently instead of using both container
and cpuset
and document the implemented behavior in a comment?
64f4056
to
495915d
Compare
495915d
to
33cb330
Compare
I need to debug this because it is still has all tasks going to lo fallback when I run:
https://github.com/likewhatevs/perfstuff/blob/main/noisy-workload.compose.yml
That being said, this does run/pass the verifier and has all the idk components needed to make this work so lmk thoughts on the approach etc.