[Arista] Disable CPU C-States other than C1 #16703
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lipxu
reviewed
Sep 27, 2023
There was a problem hiding this comment.
Hi, @Staphylo , may you please let us know what's the motivation for this PR? Are we encountering any specific issues, or is there a performance concern driving this change? if so, how much improvement can be expected? thanks a lot
|
Hi @lipxu this changes bring Arista products to parity with others using ONIE on the regard of CPU cstates. |
lipxu
approved these changes
Sep 27, 2023
Blueve
approved these changes
Oct 13, 2023
mssonicbld
pushed a commit
to mssonicbld/sonic-buildimage
that referenced
this pull request
Oct 14, 2023
Why I did it Networking devices need to be responsive. Such responsiveness is harmed when the CPU change state. There is a latency penalty when a CPU is idle (e.g C2) and need to exit this state to come back to C1 state. To prevent this from happening the CPU should be forced to remain in C1 state. How I did it Generalize the cstate forcing to C1 to all Arista products. This is done by adding processor.max_cstate=1 to the kernel cmdline for all CPUs. Additionally Intel CPUs also need intel_idle.max_cstate=0 to fallback to the acpi_idle driver. How to verify it Check that processor.max_cstate=1 is present on the cmdline for AMD CPUs Check that both processor.max_cstate=1 and intel_idle.max_cstate=0 are present on the cmdline for Intel CPUs
|
Cherry-pick PR to 202205: #16887 |
9 tasks
mssonicbld
pushed a commit
to mssonicbld/sonic-buildimage
that referenced
this pull request
Oct 14, 2023
Why I did it Networking devices need to be responsive. Such responsiveness is harmed when the CPU change state. There is a latency penalty when a CPU is idle (e.g C2) and need to exit this state to come back to C1 state. To prevent this from happening the CPU should be forced to remain in C1 state. How I did it Generalize the cstate forcing to C1 to all Arista products. This is done by adding processor.max_cstate=1 to the kernel cmdline for all CPUs. Additionally Intel CPUs also need intel_idle.max_cstate=0 to fallback to the acpi_idle driver. How to verify it Check that processor.max_cstate=1 is present on the cmdline for AMD CPUs Check that both processor.max_cstate=1 and intel_idle.max_cstate=0 are present on the cmdline for Intel CPUs
|
Cherry-pick PR to 202211: #16888 |
9 tasks
mssonicbld
added a commit
that referenced
this pull request
Oct 14, 2023
mssonicbld
added
Included in 202205 Branch
and removed
Approved for 202205 Branch
Created PR to 202205 Branch
labels
mssonicbld
pushed a commit
to mssonicbld/sonic-buildimage
that referenced
this pull request
Oct 17, 2023
Why I did it Networking devices need to be responsive. Such responsiveness is harmed when the CPU change state. There is a latency penalty when a CPU is idle (e.g C2) and need to exit this state to come back to C1 state. To prevent this from happening the CPU should be forced to remain in C1 state. How I did it Generalize the cstate forcing to C1 to all Arista products. This is done by adding processor.max_cstate=1 to the kernel cmdline for all CPUs. Additionally Intel CPUs also need intel_idle.max_cstate=0 to fallback to the acpi_idle driver. How to verify it Check that processor.max_cstate=1 is present on the cmdline for AMD CPUs Check that both processor.max_cstate=1 and intel_idle.max_cstate=0 are present on the cmdline for Intel CPUs
|
Cherry-pick PR to 202305: #16905 |
9 tasks
mssonicbld
pushed a commit
that referenced
this pull request
Oct 17, 2023
Why I did it Networking devices need to be responsive. Such responsiveness is harmed when the CPU change state. There is a latency penalty when a CPU is idle (e.g C2) and need to exit this state to come back to C1 state. To prevent this from happening the CPU should be forced to remain in C1 state. How I did it Generalize the cstate forcing to C1 to all Arista products. This is done by adding processor.max_cstate=1 to the kernel cmdline for all CPUs. Additionally Intel CPUs also need intel_idle.max_cstate=0 to fallback to the acpi_idle driver. How to verify it Check that processor.max_cstate=1 is present on the cmdline for AMD CPUs Check that both processor.max_cstate=1 and intel_idle.max_cstate=0 are present on the cmdline for Intel CPUs
mssonicbld
added
Included in 202305 Branch
and removed
Created PR to 202305 Branch
labels
2 similar comments
mssonicbld
pushed a commit
that referenced
this pull request
Oct 20, 2023
Why I did it Networking devices need to be responsive. Such responsiveness is harmed when the CPU change state. There is a latency penalty when a CPU is idle (e.g C2) and need to exit this state to come back to C1 state. To prevent this from happening the CPU should be forced to remain in C1 state. How I did it Generalize the cstate forcing to C1 to all Arista products. This is done by adding processor.max_cstate=1 to the kernel cmdline for all CPUs. Additionally Intel CPUs also need intel_idle.max_cstate=0 to fallback to the acpi_idle driver. How to verify it Check that processor.max_cstate=1 is present on the cmdline for AMD CPUs Check that both processor.max_cstate=1 and intel_idle.max_cstate=0 are present on the cmdline for Intel CPUs
mssonicbld
added
Included in 202211 Branch
and removed
Approved for 202211 Branch
Created PR to 202211 Branch
labels
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Why I did it
Networking devices need to be responsive. Such responsiveness is harmed when the CPU change state.
There is a latency penalty when a CPU is idle (e.g C2) and need to exit this state to come back to C1 state.
To prevent this from happening the CPU should be forced to remain in C1 state.
Work item tracking
How I did it
Generalize the cstate forcing to C1 to all Arista products.
This is done by adding
processor.max_cstate=1to the kernel cmdline for all CPUs.Additionally Intel CPUs also need
intel_idle.max_cstate=0to fallback to theacpi_idledriver.How to verify it
Check that
processor.max_cstate=1is present on the cmdline for AMD CPUsCheck that both
processor.max_cstate=1andintel_idle.max_cstate=0are present on the cmdline for Intel CPUsWhich release branch to backport (provide reason below if selected)
Description for the changelog
Disable CPU C-States other than C1 for Arista products