Merge pull request #55893 from ahardin-rh/cpu-manager-audit

OSDOCS-4323: Using CPU Manager and Using Topology Manager updates

Author: ahardin-rh

_topic_maps/_topic_map.yml

@@ -2497,11 +2497,9 @@ Topics:
 - Name: Using the Node Tuning Operator
   File: using-node-tuning-operator
   Distros: openshift-origin,openshift-enterprise
-- Name: Using CPU Manager
+- Name: Using CPU Manager and Topology Manager
   File: using-cpu-manager
   Distros: openshift-origin,openshift-enterprise
-- Name: Using Topology Manager
-  File: using-topology-manager
 - Name: Scheduling NUMA-aware workloads
   File: cnf-numa-aware-scheduling
   Distros: openshift-origin,openshift-enterprise

modules/pod-interactions-with-topology-manager.adoc

@@ -7,8 +7,7 @@
 
 The example `Pod` specs below help illustrate pod interactions with Topology Manager.
 
-The following pod runs in the `BestEffort` QoS class because no resource requests or
-limits are specified.
+The following pod runs in the `BestEffort` QoS class because no resource requests or limits are specified.
 
 [source,yaml]
 ----
@@ -33,8 +32,7 @@ spec:
         memory: "100Mi"
 ----
 
-If the selected policy is anything other than `none`, Topology Manager would
-not consider either of these `Pod` specifications.
+If the selected policy is anything other than `none`, Topology Manager would not consider either of these `Pod` specifications.
 
 The last example pod below runs in the Guaranteed QoS class because requests are equal to limits.
 
@@ -55,11 +53,6 @@ spec:
         example.com/device: "1"
 ----
 
-Topology Manager would consider this pod. The Topology Manager consults the
-CPU Manager static policy, which returns the topology of available CPUs. Topology
-Manager also consults Device Manager to discover the topology of available devices
-for example.com/device.
+Topology Manager would consider this pod. The Topology Manager would consult the hint providers, which are CPU Manager and Device Manager, to get topology hints for the pod.
 
-Topology Manager will use this information to store the best Topology for this
-container. In the case of this pod, CPU Manager and Device Manager will use this stored
-information at the resource allocation stage.
+Topology Manager will use this information to store the best topology for this container. In the case of this pod, CPU Manager and Device Manager will use this stored information at the resource allocation stage.

modules/setting-up-cpu-manager.adoc

@@ -51,10 +51,10 @@ spec:
      cpuManagerReconcilePeriod: 5s <2>
 ----
 <1> Specify a policy:
-* `none`. This policy explicitly enables the existing default CPU affinity scheme, providing no affinity beyond what the scheduler does automatically.
-* `static`. This policy allows pods with certain resource characteristics to be granted increased CPU affinity and exclusivity on the node. If `static`, you must use a lowercase `s`.
+* `none`. This policy explicitly enables the existing default CPU affinity scheme, providing no affinity beyond what the scheduler does automatically. This is the default policy.
+* `static`. This policy allows containers in guaranteed pods with integer CPU requests. It also limits access to exclusive CPUs on the node. If `static`, you must use a lowercase `s`.
 <2> Optional. Specify the CPU Manager reconcile frequency. The default is `5s`.
- 
+
 . Create the dynamic kubelet config:
 +
 [source,terminal]

modules/setting-up-topology-manager.adoc

@@ -11,7 +11,7 @@ To use Topology Manager, you must configure an allocation policy in the `cpumana
 
 .Prequisites
 
-* Configure the CPU Manager policy to be `static`. See the Using CPU Manager in the Scalability and Performance section.
+* Configure the CPU Manager policy to be `static`.
 
 .Procedure
 

modules/topology-manager-policies.adoc

@@ -8,11 +8,6 @@
 
 Topology Manager aligns `Pod` resources of all Quality of Service (QoS) classes by collecting topology hints from Hint Providers, such as CPU Manager and Device Manager, and using the collected hints to align the `Pod` resources.
 
-[NOTE]
-====
-To align CPU resources with other requested resources in a `Pod` spec, the CPU Manager must be enabled with the `static` CPU Manager policy.
-====
-
 Topology Manager supports four allocation policies, which you assign in the `cpumanager-enabled` custom resource (CR):
 
 `none` policy::

scalability_and_performance/using-cpu-manager.adoc

@@ -1,8 +1,8 @@
 :_content-type: ASSEMBLY
 [id='using-cpu-manager']
-= Using CPU Manager
+= Using CPU Manager and Topology Manager
 include::_attributes/common-attributes.adoc[]
-:context: using-cpu-manager
+:context: using-cpu-manager-and-topology_manager
 
 toc::[]
 
@@ -16,4 +16,18 @@ CPU Manager is useful for workloads that have some of these attributes:
 * Coordinate with other processes and benefit from sharing a single processor
 cache.
 
+Topology Manager collects hints from the CPU Manager, Device Manager, and other Hint Providers to align pod resources, such as CPU, SR-IOV VFs, and other device resources, for all Quality of Service (QoS) classes on the same non-uniform memory access (NUMA) node.
+
+Topology Manager uses topology information from the collected hints to decide if a pod can be accepted or rejected on a node, based on the configured Topology Manager policy and pod resources requested.
+
+Topology Manager is useful for workloads that use hardware accelerators to support latency-critical execution and high throughput parallel computation.
+
+To use Topology Manager you must configure CPU Manager with the `static` policy.
+
 include::modules/setting-up-cpu-manager.adoc[leveloffset=+1]
+
+include::modules/topology-manager-policies.adoc[leveloffset=+1]
+
+include::modules/setting-up-topology-manager.adoc[leveloffset=+1]
+
+include::modules/pod-interactions-with-topology-manager.adoc[leveloffset=+1]