Skip to content

cpuclass: hint all good CPU sets instead of only the best#719

Open
askervin wants to merge 1 commit into
containers:mainfrom
askervin:5iG-cpuclass-hint-alternatives
Open

cpuclass: hint all good CPU sets instead of only the best#719
askervin wants to merge 1 commit into
containers:mainfrom
askervin:5iG-cpuclass-hint-alternatives

Conversation

@askervin

Copy link
Copy Markdown
Collaborator

Satisfying CPU affinity to multiple preferences encoded in preferCloseToDevice requires more flexibility than provided in CPU class preference.

For example, a container requires PCT HP (high priority) CPUs and CPU affinity to a GPU device. There are enough HP CPUs available in both sockets. Because socket 0 happens to have fewer HP CPUs available, cpuclass hint considers it worse choice than socket 1 with more HP CPUs. However, the GPU may be connected to socket 0. As a result, preferCloseToDevices consists of a GPU-affinity hint to all CPUs on socket 0, and HP CPU affinity hint to HP CPUs on socket 1. The latter hint will be ignored, in which order they ever happen to be.

This commit changes cpuclass (HP CPUs) hints so that all good-enough CPU sets will be published. Given that cpuclass hints are applied after device (GPU) hints, above example works as follows. GPU-affinity hints all CPUs on socket 0. Next, best HP CPU affinity would hint HP CPUs on socket 1. As the intersection hinted CPUs is empty, cputree.go allocator ignores this hint. Finally, second-best HP CPU affinity hints HP CPUs on socket 0. Now intersection with already taken hints is not empty, so this hint is applied, and the container will get HP CPUs near the GPU.

Technically, this commit changes CPU class AllocationHints to contain best-first-ordered list of good-enough CPU sets as alternatives for CPU allocators to prefer.

Satisfying CPU affinity to multiple preferences encoded in
preferCloseToDevice requires more flexibility than provided in CPU
class preference.

For example, a container requires PCT HP (high priority) CPUs and CPU
affinity to a GPU device. There are enough HP CPUs available in both
sockets. Because socket 0 happens to have fewer HP CPUs available,
cpuclass hint considers it worse choice than socket 1 with more HP
CPUs. However, the GPU may be connected to socket 0. As a result,
preferCloseToDevices consists of a GPU-affinity hint to all CPUs on
socket 0, and HP CPU affinity hint to HP CPUs on socket 1. The latter
hint will be ignored, in which order they ever happen to be.

This commit changes cpuclass (HP CPUs) hints so that all good-enough
CPU sets will be published. Given that cpuclass hints are applied after
device (GPU) hints, above example works as follows. GPU-affinity hints
all CPUs on socket 0. Next, best HP CPU affinity would hint HP CPUs on
socket 1. As the intersection hinted CPUs is empty, cputree.go
allocator ignores this hint. Finally, second-best HP CPU affinity
hints HP CPUs on socket 0. Now intersection with already taken hints
is not empty, so this hint is applied, and the container will get HP
CPUs near the GPU.

Technically, this commit changes CPU class AllocationHints to contain
best-first-ordered list of good-enough CPU sets as alternatives for
CPU allocators to prefer.

Signed-off-by: Antti Kervinen <antti.kervinen@intel.com>
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.

1 participant