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.36
• 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
    • cpumanager: expand test coverage for prefer-align-cpus-by-uncore-cache kubernetes#132968
    • cpumanager: graduate prefer-align-cpus-by-uncorecache to beta kubernetes#132970
    • 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.
    • Add feature blog: introduce prefer-align-cpus-by-uncore-cache website#51484
    • KEP-4800: move to beta website#51474
• Beta
  • KEP (k/enhancements) update PR(s):
    • KEP-4800: Promote prefer-align-cpus-by-uncorecache CPUManager feature to beta #5390
  • Code (k/k) update PR(s):
    • cpumanager: uncorecache alignment for odd integer cpus kubernetes#131850
    • cpumanager: expand test coverage for prefer-align-cpus-by-uncore-cache kubernetes#132968
    • cpumanager: graduate prefer-align-cpus-by-uncorecache to beta kubernetes#132970
  • Docs (k/website) update(s):
• GA:
  • KEP ('k/enhancements') update PR(s):
    • KEP-4800: promote prefer-align-cpus-by-uncore-cache CPUManager option to GA #5849
  • Code (k/k) update PR(s):
    • promote align-uncore-cache to stable kubernetes#137055
  • Docs (k/website) update(s):
    • KEP-4800: promote prefer-align-cpus-by-uncore-cache to GA website#54484

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.

Details

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

Details

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