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
design-proposal: Support isolateEmulatorThread with SMT enabled Nodes #247
design-proposal: Support isolateEmulatorThread with SMT enabled Nodes #247
Conversation
Skipping CI for Draft Pull Request. |
d24e552
to
3febc99
Compare
/cc @vladikr @iholder101 |
3febc99
to
0f35e2f
Compare
/cc @xpivarc |
design-proposals/isolate-emulator-thread-with-smt-fix/isolate-emulator-thread-with-smt-fix.md
Outdated
Show resolved
Hide resolved
design-proposals/isolate-emulator-thread-with-smt-fix/isolate-emulator-thread-with-smt-fix.md
Outdated
Show resolved
Hide resolved
0f35e2f
to
013b628
Compare
/cc @iholder101 |
013b628
to
ccd4cfd
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.
Thank you for the PR @RamLavi
Please see the inline comments.
design-proposals/isolate-emulator-thread-with-smt-fix/isolate-emulator-thread-with-smt-fix.md
Outdated
Show resolved
Hide resolved
design-proposals/isolate-emulator-thread-with-smt-fix/isolate-emulator-thread-with-smt-fix.md
Show resolved
Hide resolved
design-proposals/isolate-emulator-thread-with-smt-fix/isolate-emulator-thread-with-smt-fix.md
Outdated
Show resolved
Hide resolved
design-proposals/isolate-emulator-thread-with-smt-fix/isolate-emulator-thread-with-smt-fix.md
Show resolved
Hide resolved
ccd4cfd
to
773c594
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.
@RamLavi Hi! Thank you raising this issue, I have a few questions below.
* We’re adding yet another semi alpha knob to an already complicated set of knobs. | ||
|
||
# Fix Alternatives | ||
## Alternative #1 Adding `full-pcpus-only` option as a global configuration |
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.
@RamLavi I am not sure whether we can consider it as alternative, because it depends on the main proposal. It can rather be an option in the implementation details, to enhance the kubevirt CR with the option to annotate every VM with the suggested annotation.
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.
@RamLavi I am not sure whether we can consider it as alternative, because it depends on the main proposal. It can rather be an option in the implementation details, to enhance the kubevirt CR with the option to annotate every VM with the suggested annotation.
I don't mean that this global option will annotate every VM once it is enabled.
I mean that this will be a global behavior, in a similar way that defaultRuntimeClass
sets the runtimeClass without changing the VM manifest (metadata or spec API) at all.
It is in that sense - that it is a different alternative.
Cons: | ||
* The suggested annotation is waisting a CPU when used on nodes with hyperthreading disabled. A cluster-wide configuration may be wasteful for heterogeneous clusters, where node-level granularity is needed. | ||
|
||
## Alternative #2 Configure both pod and Guest |
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.
@RamLavi This is also doesn't look like an alternative solution, but a suggestion to how to implement the addition of the core so that it will be even.
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 kinda agree with you here.
If this alternative is chosen then the Action item is no-op in kubevirt's perspective. I just wanted this option to be heard, as it has its advantages.
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.
Thank you for putting it writing, as this is my favorite alternative.
* Similar to the way default runtimeclass is configured on Kubevirt. | ||
|
||
Cons: | ||
* The suggested annotation is waisting a CPU when used on nodes with hyperthreading disabled. A cluster-wide configuration may be wasteful for heterogeneous clusters, where node-level granularity is needed. |
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.
@RamLavi IIUC the main proposal also has this disadvantage. I can annotate the VM and it can still be scheduled on a non-SMT node in case the cluster is heterogeneous
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.
yes but notice the scope - iIn the main proposal the scope is per VM, hence minimal (only when necessary), whereas on this alternative the impact is every VM on the cluster (!).
Considering that a standard Node has a few dozens of CPUs, this change of scope is what makes this Con - a very big and waistfull one (CPU wise).
Currently the VMI is blocked if the `kubevirt.io/CPUManagerPolicyBetaOptions` annotation set on the VMI and the CPUManagerPolicyBetaOptions feature-gate is not enabled. Removing this logic from the webhook in order to align with the design proposal [0] The meaning of this change is that if the annotation is set on the VMI manually - then the CPUManagerPolicyBetaOptions:full-pcpu-only behavior will take place in spite of the feature gate being disabled. [0] kubevirt/community#247 Signed-off-by: Ram Lavi <ralavi@redhat.com>
Currently the VMI is blocked if the `kubevirt.io/CPUManagerPolicyBetaOptions` annotation set on the VMI and the CPUManagerPolicyBetaOptions feature-gate is not enabled. Removing this logic from the webhook in order to align with the design proposal [0] The meaning of this change is that if the annotation is set on the VMI manually - then the CPUManagerPolicyBetaOptions:full-pcpu-only behavior will take place in spite of the feature gate being disabled. [0] kubevirt/community#247 Signed-off-by: Ram Lavi <ralavi@redhat.com>
The AlignCPUs feature gate is proposed [0] and introduced [1][2][3][4] on Kubevirt in order to allow support in SMT enabled nodes while using IsolateEmulatorThread on the VMI [5]. The configuration is set cluster-wide, using the kubevirt CR (annotation + kubevirt feature gate). This commit is enabling the feature-gate on the kubevirt CR when the new HCO AlignCPUs is set to true. [0] kubevirt/community#247 [1] kubevirt/kubevirt#10593 [2] kubevirt/kubevirt#10783 [3] kubevirt/kubevirt#10839 [4] kubevirt/kubevirt#10872 [5] https://bugzilla.redhat.com/show_bug.cgi?id=2228103 Signed-off-by: Ram Lavi <ralavi@redhat.com>
… annotation The alpha.kubevirt.io/EmulatorThreadCompleteToEvenParity annotation is proposed [0] and introduced [1][2][3][4] on Kubevirt in order to allow support in SMT enabled nodes while using IsolateEmulatorThread on the VMI [5]. The configuration is set cluster-wide, using the kubevirt CR (annotation + kubevirt feature gate set in previous commit). This commit is setting the annotation on the kubevirt CR if the HCO AlignCPUs feature gate is set to true. [0] kubevirt/community#247 [1] kubevirt/kubevirt#10593 [2] kubevirt/kubevirt#10783 [3] kubevirt/kubevirt#10839 [4] kubevirt/kubevirt#10872 [5] https://bugzilla.redhat.com/show_bug.cgi?id=2228103 Signed-off-by: Ram Lavi <ralavi@redhat.com>
<img src="smt-slignment-error-diagram.png"> | ||
|
||
## Goals | ||
Fix [BZ#2228103](https://bugzilla.redhat.com/show_bug.cgi?id=2228103) on the Kubevirt scope. |
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.
nit: The BZ was migrated to https://issues.redhat.com/browse/CNV-31584.
When the following conditions are met: | ||
1. The feature gate is enabled on the Kubevirt CR | ||
2. Kubevirt CR has the annotation. | ||
3. VMI is configured with `isolateEmulatorThread: true` and `dedicatedCpuPlacement: true` |
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.
The actual implementation only took isolateEmulatorThread
into account, since there is a validating webhook that runs after the mutating webhook to verity both exist.
/cc @aburdenthehand |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: aburdenthehand The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This design proposal is proposing a fix to BZ#2228103.