Merge pull request #75662 from kquinn1204/TELCODOCS-1703-416

TELCODOCS-1703 removing notes as no longer relevant Cgroups v1 and v2

Author: adellape

modules/cnf-provisioning-real-time-and-low-latency-workloads.adoc

@@ -239,11 +239,6 @@ status:
   runtimeClass: performance-manual
 ----
 
-[NOTE]
-====
-Currently, disabling CPU load balancing is not supported with cgroup v2.
-====
-
 The Node Tuning Operator is responsible for the creation of the high-performance runtime handler config snippet under relevant nodes and for creation of the high-performance runtime class under the cluster. It will have the same content as default runtime handler except it enables the CPU load balancing configuration functionality.
 
 To disable the CPU load balancing for the pod, the `Pod` specification must include the following fields:

modules/cnf-tuning-nodes-for-low-latency-via-performanceprofile.adoc

@@ -14,13 +14,6 @@ The performance profile lets you control latency tuning aspects of nodes that be
 
 You can use a performance profile to specify whether to update the kernel to kernel-rt, to allocate huge pages, and to partition the CPUs for performing housekeeping duties or running workloads.
 
-[IMPORTANT]
-====
-In {product-title} {product-version}, if you apply a performance profile to your cluster, all nodes in the cluster will reboot. This reboot includes control plane nodes and worker nodes that were not targeted by the performance profile. This is a known issue in {product-title} {product-version} because this release uses Linux control group version 2 (cgroup v2) in alignment with RHEL 9. The low latency tuning features associated with the performance profile do not support cgroup v2, therefore the nodes reboot to switch back to the cgroup v1 configuration.
-
-To revert all nodes in the cluster to the cgroups v2 configuration, you must edit the `Node` resource. (link:https://issues.redhat.com/browse/OCPBUGS-16976[*OCPBUGS-16976*])
-====
-
 [NOTE]
 ====
 You can manually create the `PerformanceProfile` object or use the Performance Profile Creator (PPC) to generate a performance profile. See the additional resources below for more information on the PPC.

modules/cnf-understanding-low-latency.adoc

@@ -20,18 +20,6 @@ Administrators must be able to manage their many Edge sites and local services i
 
 {product-title} uses the Node Tuning Operator to implement automatic tuning to achieve low latency performance for {product-title} applications. The cluster administrator uses this performance profile configuration that makes it easier to make these changes in a more reliable way. The administrator can specify whether to update the kernel to kernel-rt, reserve CPUs for cluster and operating system housekeeping duties, including pod infra containers, and isolate CPUs for application containers to run the workloads.
 
-[IMPORTANT]
-====
-In {product-title} 4.14, if you apply a performance profile to your cluster, all nodes in the cluster will reboot. This reboot includes control plane nodes and worker nodes that were not targeted by the performance profile. This is a known issue in {product-title} 4.14 because this release uses Linux control group version 2 (cgroup v2) in alignment with RHEL 9. The low latency tuning features associated with the performance profile do not support cgroup v2, therefore the nodes reboot to switch back to the cgroup v1 configuration.
-
-To revert all nodes in the cluster to the cgroups v2 configuration, you must edit the `Node` resource. (link:https://issues.redhat.com/browse/OCPBUGS-16976[*OCPBUGS-16976*])
-====
-
-[NOTE]
-====
-Currently, disabling CPU load balancing is not supported by cgroup v2. As a result, you might not get the desired behavior from performance profiles if you have cgroup v2 enabled. Enabling cgroup v2 is not recommended if you are using performance profiles.
-====
-
 {product-title} also supports workload hints for the Node Tuning Operator that can tune the `PerformanceProfile` to meet the demands of different industry environments. Workload hints are available for `highPowerConsumption` (very low latency at the cost of increased power consumption) and `realTime` (priority given to optimum latency). A combination of `true/false` settings for these hints can be used to deal with application-specific workload profiles and requirements.
 
 Workload hints simplify the fine-tuning of performance to industry sector settings. Instead of a “one size fits all” approach, workload hints can cater to usage patterns such as placing priority on: