docs/all/tuning.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. http://creativecommons.org/licenses/by/4.0
   3 .. (c) <optionally add copywriters name>
   4
   5 Low Latency Tunning Suggestion
   6 ==============================
   7
   8 The correct configuration is critical for improving the NFV performance/latency.
   9 Even working on the same codebase, configurations can cause wildly different
  10 performance/latency results.
  11
  12 There are many combinations of configurations, from hardware configuration to
  13 Operating System configuration and application level configuration. And there
  14 is no one simple configuration that works for every case. To tune a specific
  15 scenario, it's important to know the behaviors of different configurations and
  16 their impact.
  17
  18 Platform Configuration
  19 ----------------------
  20
  21 Some hardware features can be configured through firmware interface(like BIOS)
  22 but others may not be configurable (e.g. SMI on most platforms).
  23
  24 * **Power management:**
  25   Most power management related features save power at the
  26   expensive of latency. These features include: Intel®Turbo Boost Technology,
  27   Enhanced Intel®SpeedStep, Processor C state and P state. Normally they should
  28   be disabled but, depending on the real-time application design and latency
  29   requirements, there might be some features that can be enabled if the impact on
  30   deterministic execution of the workload is small.
  31
  32 * **Hyper-Threading:**
  33   The logic cores that share resource with other logic cores can introduce
  34   latency so the recommendation is to disable this feature for realtime use
  35   cases.
  36
  37 * **Legacy USB Support/Port 60/64 Emulation:**
  38   These features involve some emulation in firmware and can introduce random
  39   latency. It is recommended that they are disabled.
  40
  41 * **SMI (System Management Interrupt):**
  42   SMI runs outside of the kernel code and can potentially cause
  43   latency. It is a pity there is no simple way to disable it. Some vendors may
  44   provide related switches in BIOS but most machines do not have this capability.
  45
  46 Operating System Configuration
  47 ------------------------------
  48
  49 * **CPU isolation:**
  50   To achieve deterministic latency, dedicated CPUs should be allocated for
  51   realtime application. This can be achieved by isolating cpus from kernel
  52   scheduler. Please refer to
  53   http://lxr.free-electrons.com/source/Documentation/kernel-parameters.txt#L1608
  54   for more information.
  55
  56 * **Memory allocation:**
  57   Memory shoud be reserved for realtime applications and usually hugepage should
  58   be used to reduce page fauts/TLB misses.
  59
  60 * **IRQ affinity:**
  61   All the non-realtime IRQs should be affinitized to non realtime CPUs to
  62   reduce the impact on realtime CPUs. Some OS distributions contain an irqbalance
  63   daemon which balances the IRQs among all the cores dynamically. It should be
  64   disabled as well.
  65
  66 * **Device assignment for VM:**
  67   If a device is used in a VM, then device passthrough is desirable. In this case,
  68   the IOMMU should be enabled.
  69
  70 * **Tickless:**
  71   Frequent clock ticks cause latency. CONFIG_NOHZ_FULL should be enabled in the
  72   linux kernel. With CONFIG_NOHZ_FULL, the physical CPU will trigger many fewer
  73   clock tick interrupts(currently, 1 tick per second). This can reduce latency
  74   because each host timer interrupt triggers a VM exit from guest to host which
  75   causes performance/latency impacts.
  76
  77 * **TSC:**
  78   Mark TSC clock source as reliable. A TSC clock source that seems to be
  79   unreliable causes the kernel to continuously enable the clock source watchdog
  80   to check if TSC frequency is still correct. On recent Intel platforms with
  81   Constant TSC/Invariant TSC/Synchronized TSC, the TSC is reliable so the
  82   watchdog is useless but cause latency.
  83
  84 * **Idle:**
  85   The poll option forces a polling idle loop that can slightly improve the
  86   performance of waking up an idle CPU.
  87
  88 * **RCU_NOCB:**
  89   RCU is a kernel synchronization mechanism. Refer to
  90   http://lxr.free-electrons.com/source/Documentation/RCU/whatisRCU.txt for more
  91   information. With RCU_NOCB, the impact from RCU to the VNF will be reduced.
  92
  93 * **Disable the RT throttling:**
  94   RT Throttling is a Linux kernel mechanism that
  95   occurs when a process or thread uses 100% of the core, leaving no resources for
  96   the Linux scheduler to execute the kernel/housekeeping tasks. RT Throttling
  97   increases the latency so should be disabled.
  98
  99 * **NUMA configuration:**
 100   To achieve the best latency. CPU/Memory and device allocated for realtime
 101   application/VM should be in the same NUMA node.