Provided by: tuned_2.15.0-1_all bug

NAME

       tuned-profiles-cpu-partitioning - Partition CPUs into isolated and housekeeping.

DESCRIPTION

       The  cpu-partitioning  profile  partitions  the system CPUs into isolated and housekeeping
       CPUs. This profile is intended to be used for latency-sensitive workloads.

       An isolated CPU incurs reduced jitter and reduced interruptions by  the  kernel.  This  is
       achieved   by  clearing  the  CPU  from  user-space  processes,  movable  kernel  threads,
       interruption handlers, kernel timers, etc. The only fixed source of interruptions  is  the
       1Hz  tick  maintained  by the kernel to keep CPU usage statistics. Otherwise, the incurred
       jitter and interruptions, if any, depend on the kernel services used by the thread running
       on  the  isolated  CPU.  Threads  that run a busy loop without doing system calls, such as
       user-space drivers that access the hardware directly, are only expected to be  interrupted
       once a second by the 1Hz tick.

       A  housekeeping CPU is the opposite of an isolated CPU. Housekeeping CPUs run all daemons,
       shell processes, kernel threads, interruption handlers and work  that  can  be  dispatched
       from isolated CPUs such as disk I/O, RCU work, timers, etc.

CONFIGURATION

       The  cpu-partitioning  profile  is  configured by editing the /etc/tuned/cpu-partitioning-
       variables.conf file. There are two configuration options:

       isolated_cores=<CPU-LIST>
              List of CPUs to isolate. This option is mandatory. Any CPUs not  in  this  list  is
              automatically considered a housekeeping CPU.

       no_balance_cores=<CPU-LIST>
              List  of  CPUs  not  be  considered  by  the  kernel when doing system wide process
              load-balancing. Usually, this list should be  the  same  as  isolated_cores=.  This
              option is optional.

IMPORTANT NOTES

       * The  system should be rebooted after applying the cpu-partitioning profile for the first
         time or changing its configuration

       * The cpu-partitioning profile can be used in bare-metal and virtual machines

       * When using the cpu-partitioning profile in bare-metal, it  is  strongly  recommended  to
         "mask"  the  ksm  and  ksmtuned services in systemd (if they are installed). This can be
         done with the following command:

             # systemctl mask ksm ksmtuned

       * The cpu-partitioning profile does not use the kernel's isolcpus= feature

       * On a NUMA system, it is recommended to have at least one housekeeping CPU per NUMA node

       * The cpu-partitioning profile does not support isolating the L3 cache. This means that  a
         housekeeping  CPU  can  still  thrash  cache  entries pertaining to isolated CPUs. It is
         recommended to use cache isolation technologies to remedy this problem, such as  Intel's
         Cache Allocation Technology

       * Whether  or  not  the kernel is going to be able to deactivate the tick on isolated CPUs
         depend on a few factors concerning the running thread  behavior.   Please,  consult  the
         nohz_full documentation in the kernel to learn more

       * The  Linux  real-time  project  has  put  together  a document on the best practices for
         writing real-time applications.  Even  though  the  cpu-partitioning  profile  does  not
         guarantee  real-time  response  time,  much  of  the  techniques  for  writing real-time
         applications also apply for applications intended  to  run  under  the  cpu-partitioning
         profile. Please, refer to this document at https://rt.wiki.kernel.org

FILES

       /etc/tuned/cpu-partitioning-variables.conf
       /etc/tuned/tuned-main.conf

SEE ALSO

       tuned(8)         tuned-adm(8)         tuned-profiles(7)         tuned-profiles-realtime(7)
       tuned-profiles-nfv-host(7) tuned-profiles-nfv-guest(7)

AUTHOR

       Jaroslav Škarvada <jskarvad@redhat.com>
       Luiz Capitulino <lcapitulino@redhat.com>
       Andrew Theurer <atheurer@redhat.com>