-
Notifications
You must be signed in to change notification settings - Fork 8.9k
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
YARN-11743. Cgroup v2 support should fall back to v1 when there are no v2 controllers #7222
base: trunk
Are you sure you want to change the base?
Conversation
💔 -1 overall
This message was automatically generated. |
…o v2 controllers Change-Id: Ia6e80c5e4273af71c42e6e5efe64c7c91769a36e
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
initializeCGroupV1Handler(conf); | ||
if (cgroupsV2Enabled) { | ||
if (cgroupsV2Enabled && !isMountedInCGroupsV1(controller)) { | ||
initializeCGroupV2Handler(conf); |
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.
Just a thought: do we need to initialize the v1 handler if we're looking at clean v2 case?
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.
Thanks for the review @brumi1024! With the current logic we use the v1 handler to get the v1 controller paths and init v2 handler only if the given controller is not mounted in v1. But with a pure v2 setup I don't think we will use v1 handler after that check, there may be a cleaner way to determine this.
It's not the clean v2 setup, but with the resource plugins we still use only the v1 handler in this codepart, so probably additional checks would be needed there as well if we decide not to init the v1 handler.
Change-Id: Ia6e80c5e4273af71c42e6e5efe64c7c91769a36e
Description of PR
We should support a scenario where only cgroup v1 controllers are mounted, but cgroup v2 is enabled. Further details in the related ticket: https://issues.apache.org/jira/browse/YARN-11743
How was this patch tested?
Tested the following scenarios manually on a cluster with cgroup v2 enabled at YARN level:
The NMs could start up and jobs could run normally in every case, and the CPU and memory controller files have been updated with the limits.
For code changes:
LICENSE
,LICENSE-binary
,NOTICE-binary
files?