Home > Communication Service Provider Solutions > Telecom Multicloud Foundation > Red Hat > Guides > Red Hat Open Shift Container Platform Guides > Reference Architecture Guide: Dell Technologies - Red Hat OpenShift Reference Architecture for Telecom > Optimizing for low latency
Node performance tuning can be time-consuming and difficult to carry out in a predictable, automated manner. To reduce the difficulty of configuring highly performing nodes, OpenShift Container Platform 4.6 provides the Performance Addon Operator, which enables administrators to configure common telecommunications hardware requirements, such as the real-time kernel, huge pages, and the isolation of specific CPU cores for specific workloads. The Performance Addon Operator provides the PerformanceProfile CRD that can be used to specify the preferred low-latency configuration for a subset or all compute nodes.
The real-time kernel can be enabled in OpenShift Container Platform 4.6 on bare-metal compute nodes that are running Red Hat CoreOS. The kernel is not supported on three-node clusters or control-plane nodes, but it can be enabled through the Performance Addon Operator. This requires that customers specify which CPU cores can be used for housekeeping tasks (referred to as the "reserved" CPU set) and which CPU cores must be used exclusively to run workloads.
The primary objective of the real-time kernel is to provide consistent and predictable response times. This objective imposes additional kernel overhead due to interruptions being scheduled in separate threads, which can reduce overall throughput depending on the workload. Another impediment to low latency using the real-time kernel is the use of Intel's hyperthreading technology, which splits each physical CPU core into two logical cores, each simultaneously running an independent thread. While hyperthreading improves parallel processing performance, for consistent low latency, it can reduce throughput and negatively affect performance. To achieve consistent low latency, disabling hyperthreading may be necessary.
Depending on the use case, it may be necessary to disable hyperthreading. It is important to note which NUMA node a CPU belongs. Each CPU in the "reserved" CPU set should belong to the same NUMA node. Also, if hyperthreading is used, each logical core pair (the two logical threads that are running on a single physical core) should belong to the same CPU set (either "reserved" or "isolated").
The PerformanceProfile CRD also lets the user select a specific Topology Manager policy for NUMA node alignment. The Topology Manager performs pod alignment for various resources (CPUs and SR-IOV VFs) that exist on a specific NUMA node. The following Topology Manager policies are specifiable in a PerformanceProfile:
If the use case requires a stricter topology management policy, set either the best-effort or the restricted policy in the PerformanceProfile.
Note: For more information, see the Red Hat OpenShift Container Platform 4.6 Topology Manager documentation.
The typical memory page size is 4 Ki (or 4 kilobytes). Huge page (or hugepage) sizes in OpenShift 4.6 are either 2 Mi (512 pages) or 1 Gi (256,000 pages). The benefit of huge pages is that they reduce the chance of a Translation Lookaside Buffer (TLB) miss. The TLB is a hardware cache of page mappings that map virtual pages to the corresponding physical page of memory. If no mapping is found in the TLB, a TLB miss occurs and the virtual address that is specified by a hardware instruction must be found by translating the virtual address, which is much slower. Because the TLB size is limited by hardware and cannot be changed, the only way to reduce the number of TLB misses is to increase the page size. Huge pages in OpenShift Container Platform 4.6 must be preallocated on compute nodes that are running Red Hat CoreOS using the Performance Addon Operator and are consumed by applications by requesting a huge page resource.