Skip to content

Commit

Permalink
Add docs for Windows CPU and Memory Managers
Browse files Browse the repository at this point in the history
Signed-off-by: James Sturtevant <jsturtevant@gmail.com>
  • Loading branch information
jsturtevant committed Nov 18, 2024
1 parent 1332f3f commit e2cccab
Show file tree
Hide file tree
Showing 4 changed files with 56 additions and 3 deletions.
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
---
# Removed from Kubernetes
title: WindowsCPUAndMemoryAffinity
content_type: feature_gate

_build:
list: never
render: false

stages:
- stage: alpha
defaultValue: false
fromVersion: "1.32"
---
Add CPU and Memory Affinity support to Windows nodes with [CPUManager](/docs/tasks/administer-cluster/cpu-management-policies#windows-support), [MemoryManager](/docs/tasks/administer-cluster/memory-manager.md#windows-support) and Topology manager.
Original file line number Diff line number Diff line change
Expand Up @@ -49,6 +49,13 @@ However, in workloads where CPU cache affinity and scheduling latency
significantly affect workload performance, the kubelet allows alternative CPU
management policies to determine some placement preferences on the node.

## Windows Support

{{< feature-state for_k8s_version="v1.32" state="alpha" feature_gate_name="WindowsCPUAndMemoryAffinity" >}}

The CPU Manager support can be enabled on Windows by using the `WindowsCPUAndMemoryAffinity` feature flag and requires a support in the container runtime.
Once feature is enabled follow the steps above to configure the [CPU Manager Policy](#configuration).

### Configuration

The CPU Manager policy is set with the `--cpu-manager-policy` kubelet
Expand Down
31 changes: 28 additions & 3 deletions content/en/docs/tasks/administer-cluster/memory-manager.md
Original file line number Diff line number Diff line change
Expand Up @@ -46,7 +46,7 @@ Preceding v1.22, the `kubelet` must be started with the following flag:

in order to enable the Memory Manager feature.

## How Memory Manager Operates?
## How does the Memory Manager Operates?

The Memory Manager currently offers the guaranteed memory (and hugepages) allocation
for Pods in Guaranteed QoS class.
Expand All @@ -57,7 +57,7 @@ prepare and deploy a `Guaranteed` pod as illustrated in the section

The Memory Manager is a Hint Provider, and it provides topology hints for
the Topology Manager which then aligns the requested resources according to these topology hints.
It also enforces `cgroups` (i.e. `cpuset.mems`) for pods.
On Linux, it also enforces `cgroups` (i.e. `cpuset.mems`) for pods.
The complete flow diagram concerning pod admission and deployment process is illustrated in
[Memory Manager KEP: Design Overview][4] and below:

Expand Down Expand Up @@ -91,6 +91,12 @@ The problem has been solved as elaborated in
Also, reference [Memory Manager KEP: Simulation - how the Memory Manager works? (by examples)][1]
illustrates how the management of groups occurs.

### Windows Support

{{< feature-state for_k8s_version="v1.32" state="alpha" feature_gate_name="WindowsCPUAndMemoryAffinity" >}}

Windows support can be enabled via the `WindowsCPUAndMemoryAffinity` feature gate and requires a support in the container runtime. Only the [BestEffort Policy](#policy-best-effort) is supported on Windows.

## Memory Manager configuration

Other Managers should be first pre-configured. Next, the Memory Manager feature should be enabled
Expand All @@ -103,7 +109,8 @@ node stability (section [Reserved memory flag](#reserved-memory-flag)).
Memory Manager supports two policies. You can select a policy via a `kubelet` flag `--memory-manager-policy`:

* `None` (default)
* `Static`
* `Static` (Linux only)
* `BestEffort` (Windows Only)

#### None policy {#policy-none}

Expand All @@ -123,6 +130,24 @@ In the case of the `BestEffort` or `Burstable` pod, the `Static` Memory Manager
the default topology hint as there is no request for the guaranteed memory,
and does not reserve the memory in the internal [NodeMap][2] object.

This policy is only Supported on Linux.

#### BestEffort policy {#policy-best-effort}

{{< feature-state for_k8s_version="v1.32" state="alpha" feature_gate_name="WindowsCPUAndMemoryAffinity" >}}

This policy is only Support on Windows.

On Windows, NUMA node assignment works differently than Linux. There is no mechanism
to ensure that Memory access only comes from a specific NUMA node, instead the Windows
internals will select the most optimal NUMA node based on the CPU assignment and it is
possible that Windows might use other nodes if required or deemed optimal. For this
reason this policy is best effort.

The policy does track the amount of memory available and requested through the internal
[NodeMap][2] to make a best effort at ensuring that memory enough memory is available on
a NUMA node before making the hint to assign it to the NODE. This means that in most cases, this should function as expected.

### Reserved memory flag

The [Node Allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/) mechanism
Expand Down
6 changes: 6 additions & 0 deletions content/en/docs/tasks/administer-cluster/topology-manager.md
Original file line number Diff line number Diff line change
Expand Up @@ -58,6 +58,12 @@ the pod can be accepted or rejected from the node based on the selected hint.
The hint is then stored in the Topology Manager for use by the *Hint Providers* when making the
resource allocation decisions.

## Windows Support

{{< feature-state for_k8s_version="v1.32" state="alpha" feature_gate_name="WindowsCPUAndMemoryAffinity" >}}

The Topology Manager support can be enabled on Windows by using the `WindowsCPUAndMemoryAffinity` feature flag and requires a support in the container runtime.

## Topology manager scopes and policies

The Topology Manager currently:
Expand Down

0 comments on commit e2cccab

Please sign in to comment.