openshift · aireilly · May 10, 2024 · Feb 19, 2024
diff --git a/_topic_maps/_topic_map.yml b/_topic_maps/_topic_map.yml
@@ -2901,14 +2901,21 @@ Topics:
   File: what-huge-pages-do-and-how-they-are-consumed-by-apps
   Distros: openshift-origin,openshift-enterprise
 - Name: Low latency tuning
-  File: cnf-low-latency-tuning
+  Dir: low_latency_tuning
   Distros: openshift-origin,openshift-enterprise
-- Name: Performing latency tests for platform verification
-  File: cnf-performing-platform-verification-latency-tests
+  Topics:
+  - Name: Understanding low latency
+    File: cnf-understanding-low-latency
+  - Name: Tuning nodes for low latency with the performance profile
+    File: cnf-tuning-low-latency-nodes-with-perf-profile
+  - Name: Provisioning real-time and low latency workloads
+    File: cnf-provisioning-low-latency-workloads
+  - Name: Debugging low latency tuning
+    File: cnf-debugging-low-latency-tuning-status
+  - Name: Performing latency tests for platform verification
+    File: cnf-performing-platform-verification-latency-tests
 - Name: Improving cluster stability in high latency environments using worker latency profiles
   File: scaling-worker-latency-profiles
-- Name: Creating a performance profile
-  File: cnf-create-performance-profiles
   Distros: openshift-origin,openshift-enterprise
 - Name: Workload partitioning
   File: enabling-workload-partitioning

diff --git a/installing/installing-preparing.adoc b/installing/installing-preparing.adoc
@@ -112,7 +112,7 @@ For a production cluster, you must configure the following integrations:
 [id="installing-preparing-cluster-for-workloads"]
 == Preparing your cluster for workloads
 
-Depending on your workload needs, you might need to take extra steps before you begin deploying applications. For example, after you prepare infrastructure to support your application xref:../cicd/builds/build-strategies.adoc#build-strategies[build strategy], you might need to make provisions for xref:../scalability_and_performance/cnf-low-latency-tuning.adoc#cnf-low-latency-tuning[low-latency] workloads or to xref:../nodes/pods/nodes-pods-secrets.adoc#nodes-pods-secrets[protect sensitive workloads]. You can also configure xref:../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects[monitoring] for application workloads.
+Depending on your workload needs, you might need to take extra steps before you begin deploying applications. For example, after you prepare infrastructure to support your application xref:../cicd/builds/build-strategies.adoc#build-strategies[build strategy], you might need to make provisions for xref:../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#cnf-low-latency-perf-profile[low-latency] workloads or to xref:../nodes/pods/nodes-pods-secrets.adoc#nodes-pods-secrets[protect sensitive workloads]. You can also configure xref:../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects[monitoring] for application workloads.
 If you plan to run xref:../windows_containers/enabling-windows-container-workloads.adoc#enabling-windows-container-workloads[Windows workloads], you must enable xref:../networking/ovn_kubernetes_network_provider/configuring-hybrid-networking.adoc#configuring-hybrid-networking[hybrid networking with OVN-Kubernetes] during the installation process; hybrid networking cannot be enabled after your cluster is installed.
 
 [id="supported-installation-methods-for-different-platforms"]

diff --git a/installing/installing_openstack/installing-openstack-nfv-preparing.adoc b/installing/installing_openstack/installing-openstack-nfv-preparing.adoc
@@ -42,4 +42,5 @@ After you perform preinstallation tasks, install your cluster by following the m
 * Consult the following references after you deploy your cluster to improve its performance:
 ** xref:../../networking/hardware_networks/using-dpdk-and-rdma.adoc#nw-openstack-ovs-dpdk-testpmd-pod_using-dpdk-and-rdma[A test pod template for clusters that use OVS-DPDK on OpenStack].
 ** xref:../../networking/hardware_networks/add-pod.adoc#nw-openstack-sr-iov-testpmd-pod_add-pod[A test pod template for clusters that use SR-IOV on OpenStack].
-** xref:../../scalability_and_performance/cnf-create-performance-profiles.adoc#installation-openstack-ovs-dpdk-performance-profile_cnf-create-performance-profiles[A performance profile template for clusters that use OVS-DPDK on OpenStack].
+** xref:../../scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc#installation-openstack-ovs-dpdk-performance-profile_cnf-low-latency-perf-profile[A performance profile template for clusters that use OVS-DPDK on OpenStack]
+.
diff --git a/modules/cnf-about-hyperthreading-for-low-latency-and-real-time-applications.adoc b/modules/cnf-about-hyperthreading-for-low-latency-and-real-time-applications.adoc
@@ -0,0 +1,16 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/low_latency_tuning/cnf-understanding-low-latency.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="cnf-about-hyper-threading-for-low-latency-and-real-time-applications_{context}"]
+= About Hyper-Threading for low latency and real-time applications
+
+Hyper-Threading is an Intel processor technology that allows a physical CPU processor core to function as two logical cores, executing two independent threads simultaneously. Hyper-Threading allows for better system throughput for certain workload types where parallel processing is beneficial. The default {product-title} configuration expects Hyper-Threading to be enabled.
+
+For telecommunications applications, it is important to design your application infrastructure to minimize latency as much as possible. Hyper-Threading can slow performance times and negatively affect throughput for compute-intensive workloads that require low latency. Disabling Hyper-Threading ensures predictable performance and can decrease processing times for these workloads.
+
+[NOTE]
+====
+Hyper-Threading implementation and configuration differs depending on the hardware you are running {product-title} on. Consult the relevant host hardware tuning information for more details of the Hyper-Threading implementation specific to that hardware. Disabling Hyper-Threading can increase the cost per core of the cluster.
+====
diff --git a/modules/cnf-about-irq-affinity-setting.adoc b/modules/cnf-about-irq-affinity-setting.adoc
@@ -1,10 +1,11 @@
 // Module included in the following assemblies:
 //
-// scalability_and_performance/cnf-low-latency-tuning.adoc
+// * scalability_and_performance/cnf-low-latency-tuning.adoc
+// * scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc
 
 :_mod-docs-content-type: CONCEPT
 [id="about_irq_affinity_setting_{context}"]
-= About support of IRQ affinity setting
+= Finding the effective IRQ affinity setting for a node
 
 Some IRQ controllers lack support for IRQ affinity setting and will always expose all online CPUs as the IRQ mask. These IRQ controllers effectively run on CPU 0.
 
@@ -60,4 +61,4 @@ $ find /proc/irq -name effective_affinity -printf "%p: " -exec cat {} \;
 /proc/irq/34/effective_affinity: 2
 ----
 
-Some drivers use `managed_irqs`, whose affinity is managed internally by the kernel and userspace cannot change the affinity. In some cases, these IRQs might be assigned to isolated CPUs. For more information about `managed_irqs`, see link:https://access.redhat.com/solutions/4819541[Affinity of managed interrupts cannot be changed even if they target isolated CPU].
+Some drivers use `managed_irqs`, whose affinity is managed internally by the kernel and userspace cannot change the affinity. In some cases, these IRQs might be assigned to isolated CPUs. For more information about `managed_irqs`, see link:https://access.redhat.com/solutions/4819541[Affinity of managed interrupts cannot be changed even if they target isolated CPU].
diff --git a/modules/cnf-about-the-profile-creator-tool.adoc b/modules/cnf-about-the-profile-creator-tool.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
-// Epic CNF-792 (4.8)
-// * scalability_and_performance/cnf-create-performance-profiles.adoc
+//
+// * scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc
 
 :_mod-docs-content-type: CONCEPT
 [id="cnf-about-the-profile-creator-tool_{context}"]

diff --git a/modules/cnf-about_hyperthreading_for_low_latency_and_real_time_applications.adoc b/modules/cnf-about_hyperthreading_for_low_latency_and_real_time_applications.adoc
diff --git a/modules/cnf-adjusting-nic-queues-with-the-performance-profile.adoc b/modules/cnf-adjusting-nic-queues-with-the-performance-profile.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
-//CNF-1483 (4.8)
-// * scalability_and_performance/low-latency-tuning.adoc
+//
+// * scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="adjusting-nic-queues-with-the-performance-profile_{context}"]
@@ -165,4 +165,4 @@ spec:
 [source,terminal]
 ----
 $ oc apply -f <your_profile_name>.yaml
-----
+----
diff --git a/modules/cnf-allocating-multiple-huge-page-sizes.adoc b/modules/cnf-allocating-multiple-huge-page-sizes.adoc
@@ -1,7 +1,7 @@
-// CNF-538 Promote Multiple Huge Pages Sizes for Pods and Containers to beta
 // Module included in the following assemblies:
 //
-// *scalability_and_performance/cnf-low-latency-tuning.adoc
+// * scalability_and_performance/cnf-low-latency-tuning.adoc
+// * scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc
 
 [id="cnf-allocating-multiple-huge-page-sizes_{context}"]
 = Allocating multiple huge page sizes
@@ -22,4 +22,4 @@ spec:
     - count: 4
       node: 1
       size: 1G
-----
+----
diff --git a/modules/cnf-collecting-low-latency-tuning-debugging-data-for-red-hat-support.adoc b/modules/cnf-collecting-low-latency-tuning-debugging-data-for-red-hat-support.adoc
@@ -1,7 +1,7 @@
-// CNF-643 Support and debugging tools for CNF
 // Module included in the following assemblies:
 //
-// *scalability_and_performance/cnf-low-latency-tuning.adoc
+// * scalability_and_performance/cnf-low-latency-tuning.adoc
+// * scalability_and_performance/low_latency_tuning/cnf-debugging-low-latency-tuning-status.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="cnf-collecting-low-latency-tuning-debugging-data-for-red-hat-support_{context}"]

diff --git a/modules/cnf-configure_for_irq_dynamic_load_balancing.adoc b/modules/cnf-configure_for_irq_dynamic_load_balancing.adoc
@@ -176,4 +176,4 @@ find /proc/irq/ -name smp_affinity_list -exec sh -c 'i="$1"; mask=$(cat $i); fil
 /proc/irq/28/smp_affinity_list: 1
 /proc/irq/29/smp_affinity_list: 0
 /proc/irq/30/smp_affinity_list: 0-5
-----
+----
diff --git a/modules/cnf-configuring-high-priority-workload-pods.adoc b/modules/cnf-configuring-high-priority-workload-pods.adoc
@@ -0,0 +1,55 @@
+// Module included in the following assemblies:
+//
+// * scalability_and_performance/low_latency_tuning/cnf-provisioning-low-latency-workloads.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="cnf-configuring-high-priority-workload-pods_{context}"]
+= Disabling power saving mode for high priority pods
+
+You can configure pods to ensure that high priority workloads are unaffected when you configure power saving for the node that the workloads run on.
+
+When you configure a node with a power saving configuration, you must configure high priority workloads with performance configuration at the pod level, which means that the configuration applies to all the cores used by the pod.
+
+By disabling P-states and C-states at the pod level, you can configure high priority workloads for best performance and lowest latency.
+
+.Configuration for high priority workloads
+[cols="1,2,3", options="header"]
+
+|===
+| Annotation | Possible Values | Description
+
+|`cpu-c-states.crio.io:` a|  * `"enable"`
+* `"disable"`
+* `"max_latency:microseconds"` | This annotation allows you to enable or disable C-states for each CPU. Alternatively, you can also specify a maximum latency in microseconds for the C-states. For example, enable C-states with a maximum latency of 10 microseconds with the setting `cpu-c-states.crio.io`: `"max_latency:10"`. Set the value to `"disable"` to provide the best performance for a pod.
+
+| `cpu-freq-governor.crio.io:` | Any supported `cpufreq governor`. | Sets the `cpufreq` governor for each CPU. The `"performance"` governor is recommended for high priority workloads.
+|===
+
+.Prerequisites
+
+* You have configured power saving in the performance profile for the node where the high priority workload pods are scheduled.
+
+.Procedure
+
+. Add the required annotations to your high priority workload pods. The annotations override the `default` settings.
++
+.Example high priority workload annotation
+[source,yaml]
+----
+apiVersion: v1
+kind: Pod
+metadata:
+  #...
+  annotations:
+    #...
+    cpu-c-states.crio.io: "disable"
+    cpu-freq-governor.crio.io: "performance"
+    #...
+  #...
+spec:
+  #...
+  runtimeClassName: performance-<profile_name>
+  #...
+----
+
+. Restart the pods to apply the annotation.
diff --git a/modules/cnf-configuring-huge-pages.adoc b/modules/cnf-configuring-huge-pages.adoc
@@ -1,6 +1,7 @@
 // Module included in the following assemblies:
-//CNF-78 (4.4)
+//
 // * scalability_and_performance/cnf-low-latency-tuning.adoc
+// * scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc
 
 [id="cnf-configuring-huge-pages_{context}"]
 = Configuring huge pages

diff --git a/...iguring_hyperthreading_for_a_cluster.adoc → ...iguring-hyperthreading-for-a-cluster.adoc b/...iguring_hyperthreading_for_a_cluster.adoc → ...iguring-hyperthreading-for-a-cluster.adoc
@@ -1,21 +1,21 @@
 // Module included in the following assemblies:
 //
-// scalability_and_performance/cnf-low-latency-tuning.adoc
+// * scalability_and_performance/low_latency_tuning/cnf-tuning-low-latency-nodes-with-perf-profile.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="configuring_hyperthreading_for_a_cluster_{context}"]
-= Configuring hyperthreading for a cluster
+[id="cnf-configuring-hyperthreading-for-a-cluster_{context}"]
+= Configuring Hyper-Threading for a cluster
 
-To configure hyperthreading for an {product-title} cluster, set the CPU threads in the performance profile to the same cores that are configured for the reserved or isolated CPU pools.
+To configure Hyper-Threading for an {product-title} cluster, set the CPU threads in the performance profile to the same cores that are configured for the reserved or isolated CPU pools.
 
 [NOTE]
 ====
-If you configure a performance profile, and subsequently change the hyperthreading configuration for the host, ensure that you update the CPU `isolated` and `reserved` fields in the `PerformanceProfile` YAML to match the new configuration.
+If you configure a performance profile, and subsequently change the Hyper-Threading configuration for the host, ensure that you update the CPU `isolated` and `reserved` fields in the `PerformanceProfile` YAML to match the new configuration.
 ====
 
 [WARNING]
 ====
-Disabling a previously enabled host hyperthreading configuration can cause the CPU core IDs listed in the `PerformanceProfile` YAML to be incorrect. This incorrect configuration can cause the node to become unavailable because the listed CPUs can no longer be found.
+Disabling a previously enabled host Hyper-Threading configuration can cause the CPU core IDs listed in the `PerformanceProfile` YAML to be incorrect. This incorrect configuration can cause the node to become unavailable because the listed CPUs can no longer be found.
 ====
 
 .Prerequisites
@@ -51,7 +51,7 @@ CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ    MINMHZ
 +
 In this example, there are eight logical CPU cores running on four physical CPU cores. CPU0 and CPU4 are running on physical Core0, CPU1 and CPU5 are running on physical Core 1, and so on.
 +
-Alternatively, to view the threads that are set for a particular physical CPU core (`cpu0` in the example below), open a command prompt and run the following:
+Alternatively, to view the threads that are set for a particular physical CPU core (`cpu0` in the example below), open a shell prompt and run the following:
 +
 [source,terminal]
 ----
@@ -83,20 +83,23 @@ The reserved and isolated CPU pools must not overlap and together must span all
 
 [IMPORTANT]
 ====
-Hyperthreading is enabled by default on most Intel processors. If you enable hyperthreading, all threads processed by a particular core must be isolated or processed on the same core.
+Hyper-Threading is enabled by default on most Intel processors. If you enable Hyper-Threading, all threads processed by a particular core must be isolated or processed on the same core.
+
+When Hyper-Threading is enabled, all guaranteed pods must use multiples of the simultaneous multi-threading (SMT) level to avoid a "noisy neighbor" situation that can cause the pod to fail.
+See link:https://kubernetes.io/docs/tasks/administer-cluster/cpu-management-policies/#static-policy-options[Static policy options] for more information.
 ====
 
 [id="disabling_hyperthreading_for_low_latency_applications_{context}"]
-== Disabling hyperthreading for low latency applications
+== Disabling Hyper-Threading for low latency applications
 
-When configuring clusters for low latency processing, consider whether you want to disable hyperthreading before you deploy the cluster. To disable hyperthreading, do the following:
+When configuring clusters for low latency processing, consider whether you want to disable Hyper-Threading before you deploy the cluster. To disable Hyper-Threading, perform the following steps:
 
 . Create a performance profile that is appropriate for your hardware and topology.
 . Set `nosmt` as an additional kernel argument. The following example performance profile illustrates this setting:
 +
 [source,yaml]
 ----
-apiVersion: performance.openshift.io/v2
+apiVersion: performance.openshift.io/v2
 kind: PerformanceProfile
 metadata:
   name: example-performanceprofile