Split L3 Cache Topology Awareness in CPU Manager

[ajcaldelas]

Enhancement Description

• One-line enhancement description (can be used as a release note):
  We proposed this KEP to introduce a new CPU Manager static policy option that makes best effort to align CPU resources by L3 (last-level) cache.
• Kubernetes Enhancement Proposal: https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/4800-cpumanager-split-uncorecache/README.md (original in https://docs.google.com/document/d/1LpnMjGNsQyHOuVHMktIrjZsdRw9aKZ8djt354nAno6M/edit?usp=sharing) Previous issue Enhance CPU manager with L3 cache aware #2621
• Discussion Link:
• Backlinking issue: Split L3 Cache Topology Awareness in CPU Manager #4800
• Primary contact (assignee): @wongchar, @ajcaldelas
• Responsible SIGs: Node
• Enhancement target (which target equals to which milestone):
• Alpha release target (x.y): 1.33
  • No documentation changes are planned for this release.
• Beta release target (x.y): 1.34
• Stable release target (x.y): 1.35
• Alpha
  • KEP (k/enhancements)
    update PR(s):
    KEP-4800: Split UnCoreCache awareness #4810
    KEP-4800: Split Uncore Cache Toplogy Awareness Alignment #5110
  • Code (k/k) update PR(s):
    • Split L3 Cache Topology Awareness in CPU Manager kubernetes#126750
    • node: cpumgr: metrics: add uncore cache alignment metrics kubernetes#130133
    • node: cpumanager: prefer-align-cpus-by-uncorecache: add test cases and CPU topologies kubernetes#130153
  • Docs
    • (k/website) update PR(s): Add prefer-align-cpus-by-uncorecache feature gate website#48340
    • No documentation changes required for the 1.33 release.

Please keep this description up to date. This will help the Enhancement Team to track the evolution of the enhancement efficiently.

[ajcaldelas]

/sig node
/assign @ajcaldelas @wongchar

[k8s-ci-robot]

@ajcaldelas: The label(s) sig/sig-node cannot be applied, because the repository doesn't have them.

In response to this:

/sig sig-node
/assign @ajcaldelas @wongchar

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[k8s-ci-robot]

@ajcaldelas: GitHub didn't allow me to assign the following users: wongchar.

Note that only kubernetes members with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

/sig sig-node
/assign @ajcaldelas @wongchar

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[kannon92]

I don't understand why #4800 is not sufficient.

Is this a duplicate?

[ajcaldelas]

I don't understand why #4800 is not sufficient.

Is this a duplicate?

From what I understand since the original author is no longer contributing atm, we need to create a new issue and backlink the original issue. This is not a duplicate in that sense, I mentioned a reference to it in the issue description.

@ffromani if you could chime in that would be appreciated.

[ffromani]

I don't understand why #4800 is not sufficient.

Is this a duplicate?

this is another case on which we have to adopt an issue because AFAIU the original contributor is no longer active and someone else is taking over.
The current approach (which I suggested indeed offline) seems the less bad to me but I'm open to suggestions.

[ffromani]

started a thread on sig-arch to see if we can improve this take-over process https://kubernetes.slack.com/archives/C5P3FE08M/p1738311284411229

[ffromani]

/sig node

please review examples of other takeovers. Examples (there are others):
#3570
#3743

[kannon92]

Taking over this is fine. It wasn't clear in the description.

Can you make sure the KEP template follows others? The markdown seems off.

[ajcaldelas]

Can you be specific? I directly copied it from the repo so I'm not sure what's off about it

[kannon92]

#4800 looks different than yours.

It is the markdown formatting that differs not the content but let's try to be consistent.

[wongchar]

/assign @wongchar

[haircommander]

/label lead-opted-in
/milestone v1.33

note: PRR freeze is tomorrow! you need to have a KEP update for this opened before then. Thanks!

[jenshu]

Hello @wongchar, @ajcaldelas 👋, v1.33 Enhancements team here.

Just checking in as we approach enhancements freeze on 02:00 UTC Friday 14th February 2025 / 19:00 PDT Thursday 13th February 2025.

This enhancement is targeting stage alpha for v1.33 (correct me, if otherwise)

Here's where this enhancement currently stands:

• KEP readme using the latest template has been merged into the k/enhancements repo.
• KEP status is marked as implementable for latest-milestone: v1.33.
• KEP readme has up-to-date graduation criteria
• KEP has a production readiness review that has been completed and merged into k/enhancements. (For more information on the PRR process, check here). If your production readiness review is not completed yet, please make sure to fill the production readiness questionnaire in your KEP by the PRR Freeze deadline on Thursday 6th February 2025 so that the PRR team has enough time to review your KEP.

For this KEP, we would just need to update the following:

• in the kep.yaml, the latest-milestone should be updated to v1.33 (I see that you have a PR open that will take care of that)

The status of this enhancement is marked as At risk for enhancements freeze. Please keep the issue description up-to-date with appropriate stages as well.

If you anticipate missing enhancements freeze, you can file an exception request in advance. Thank you!

[dipesh-rawat]

Hi @wongchar, @ajcaldelas 👋, 1.33 Enhancements team here,

Just a quick friendly reminder as we approach the enhancements freeze later this week, at 02:00 UTC Friday 14th February 2025 / 19:00 PDT Thursday 13th February 2025.

The current status of this enhancement is marked as At risk for enhancement freeze. There are a few requirements mentioned in the comment #5109 (comment) that still need to be completed.

If you anticipate missing enhancements freeze, you can file an exception request in advance. Thank you!

[jenshu]

Hello @wongchar, @ajcaldelas 👋, v1.33 Enhancements team here.

With all the requirements fulfilled, this enhancement is now marked as tracked for the upcoming enhancements freeze 🚀

[wongchar]

No changes to official Kubernetes documentation for v1.33 release but plan to add a blog post in the future

[aibarbetta]

Hi @wongchar, @ajcaldelas 👋 -- this is Agustina (@aibarbetta) from the 1.33 Communications Team!

For the 1.33 release, we are currently in the process of collecting and curating a list of potential feature blogs, and we'd love for you to consider writing one for your enhancement!

As you may be aware, feature blogs are a great way to communicate to users about features which fall into (but not limited to) the following categories:

• This introduces some breaking change(s)
• This has significant impacts and/or implications to users
• ...Or this is a long-awaited feature, which would go a long way to cover the journey more in detail 🎉

To opt in to write a feature blog, could you please let us know and open a "Feature Blog placeholder PR" (which can be only a skeleton at first) against the website repository by Wednesday, 5th March, 2025? For more information about writing a blog, please find the blog contribution guidelines 📚

Tip

Some timeline to keep in mind:

• 02:00 UTC Wednesday, 5th March, 2025: Feature blog PR freeze
• Monday, 7th April, 2025: Feature blogs ready for review
• You can find more in the release document

Note

In your placeholder PR, use XX characters for the blog date in the front matter and file name. We will work with you on updating the PR with the publication date once we have a final number of feature blogs for this release.

[aibarbetta]

Hi @wongchar, @ajcaldelas 👋, 1.33 Communications Team here again!

This is a gentle reminder for the feature blog deadline mentioned above, which is 02:00 UTC Wednesday, 5th March, 2025. To opt in, please let us know and open a Feature Blog placeholder PR against k/website by the deadline. If you have any questions, please feel free to reach out to us!

Tip

Some timeline to keep in mind:

• 02:00 UTC Wednesday, 5th March, 2025: Feature blog PR freeze
• Monday, 7th April, 2025: Feature blogs ready for review
• You can find more in the release document

Note

In your placeholder PR, use XX characters for the blog date in the front matter and file name. We will work with you on updating the PR with the publication date once we have a final number of feature blogs for this release.

[jenshu]

Hey again @wongchar @ajcaldelas 👋, v1.33 Enhancements team here.

Just checking in as we approach code freeze at 02:00 UTC Friday 21st March 2025 / 19:00 PDT Thursday 20th March 2025.

Here's where this enhancement currently stands:

• All PRs to the Kubernetes repo that are related to your enhancement are linked in the above issue description (for tracking purposes).
• All PRs are ready to be merged (they have approved and lgtm labels applied) by the code freeze deadline. This includes tests.

Per the issue description, these are all of the implementation (code-related) PRs for 1.33, some of which are not merged yet:

• Split L3 Cache Topology Awareness in CPU Manager kubernetes#126750
• node: cpumgr: metrics: add uncore cache alignment metrics kubernetes#130133
• node: cpumanager: prefer-align-cpus-by-uncorecache: add test cases and CPU topologies kubernetes#130153

Please let me know (and keep the issue description updated) if there are any other PRs in k/k that we should track for this KEP, so that we can maintain accurate status.

If you anticipate missing code freeze, you can file an exception request in advance.

The status of this enhancement is marked as At risk for code freeze.