Skip to content
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

cpuallocator: implement clustered allocation based on cache groups. #343

Merged
merged 5 commits into from
Jul 5, 2024

Conversation

klihub
Copy link
Collaborator

@klihub klihub commented Jun 26, 2024

This patch series adds support for clustered CPU allocation based on cache groups to the cpuallocator package. In particular with these patches in place, the cpuallocator now

  • discovers cache groups on instantiation
  • tries to satisfy allocation requests using one or more cache groups
  • uses explicit cluster info based allocation only on hybrid core architectures

Allocation always prefers using fully idle cache groups first, fragmenting idle cache groups by partial allocation second, and only resort to using fragmented groups when the allocation cannot be satisfied in any other way. Partial cache group allocations are done in a hyperthread aware fashion, taking full physical cores whenever possible.

The allocator uses the last useful level of cache for clustering. IOW it tries to find the last cache which provides non-trivial clustering, one that provides different grouping than packages, dies, or hyperthreading, and uses that for grouping CPUs. The current implementation is currently somewhat simplistic as it expects all CPUs to provide identical cache grouping and therefore picks a single cache level for grouping. This is fine on most architectures, but it might result in suboptimal clustering with hybrid cores. If necessary this limitation can be addressed in the future.

Add GetNthLevelCacheCPUSet() akin to GetLastLevelCacheCPUSet()
but returning the nth level cache cpuset for the CPU.

Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
@klihub klihub force-pushed the devel/cache-group-allocation branch 3 times, most recently from 366a62e to 430e7fc Compare June 26, 2024 12:07
pkg/sysfs/system.go Show resolved Hide resolved
pkg/cpuallocator/allocator.go Outdated Show resolved Hide resolved
pkg/cpuallocator/allocator.go Outdated Show resolved Hide resolved
pkg/cpuallocator/allocator.go Show resolved Hide resolved
Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Discover groups of CPUs sharing a cache. Ignore groups which
happen to be the same as CPUs grouped by some other topology
criteria (package, die, etc.). Assume that all CPUs within a
group are from the same package and die, and share the same
closest NUMA node. Verify this assumption during discovery,
aborting with a panic if it is not true.

Use the last useful level of cache for clustering, IOW try
finding the last cache which provides non-trivial clustering
and use it grouping. Note that the current implementation is
somewhat simplistic. It expects all CPUs to provide identical
cache grouping and therefore picks a single cache level. This
is usually fine, but it might result in suboptimal clustering
with hybrid cores. If necessary we can remove this limitation
in the future.

Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Implement cache group based CPU allocation. When a request
makes this possible, try to satisfy it by allocating one or
more cache groups. Always prefer using fully idle cache groups
first, fragmenting idle cache groups by partial allocation
second, and only resort to using fragmented groups when the
allocation cannot be satisfied in any other way. When doing
partial allocations, do it in a hyperthreading aware fashion,
taking full physical cores whenever possible.

Note:
  This allocation algorithm is a modified version of the
  cluster based allocator. We might want to try and combine
  them into a single group based allocator in the future.

Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Use explicit cluster info based allocation only on hybrid core
platforms. In other cases omit it altogether only using cache
group based allocation. These should provide identical groups
but for cache groups we do have partial allocation implemented
while for cluster groups we don't have ATM.

Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
@klihub klihub force-pushed the devel/cache-group-allocation branch from 430e7fc to e4ed880 Compare June 28, 2024 16:17
@klihub klihub requested a review from askervin June 28, 2024 16:18
Copy link
Collaborator

@askervin askervin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks Great. Thanks @klihub!

@askervin askervin merged commit 28c2b27 into containers:main Jul 5, 2024
2 checks passed
@klihub klihub deleted the devel/cache-group-allocation branch July 5, 2024 16:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants