The attached test code is borrowed from Jay, it measures the average time for running getpid() 100000000 times to see if NO_HZ_FULL will cause any performance degradation for context switch when it’s built into kernel
There are 4 test scopes: 1. Without NO_HZ_FULL built-in the default value of NO_HZ is NO_HZ_IDLE in ubuntu kernel 2. With NO_HZ_FULL built-in, but not activate it in kernel cmdline 3. With NO_HZ_FULL built-in, and activate nohz_full on some CPUs (also isolcpu and rcu_nocbs) in kernel cmdline 4. With NO_HZ_FULL built-in, and activate nohz_full on some CPUs, but run test program on a non-activate nohz_full CPU For the first 3 test scopes above also contain two test cases 1. Not pin the test program 2. Pin the test program to a specific CPU, in my test, it’s pinned to CPU 4 as below taskset --cpu-list 4 ./test For the forth test scope, only pin the test program to a specific CPU which is not in nohz_full -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1919154 Title: Enable CONFIG_NO_HZ_FULL on supported architectures Status in linux package in Ubuntu: In Progress Status in linux source package in Focal: In Progress Status in linux source package in Groovy: Won't Fix Status in linux source package in Hirsute: In Progress Status in linux source package in Jammy: In Progress Status in linux source package in Lunar: In Progress Status in linux source package in Mantic: In Progress Bug description: [Impact] The CONFIG_NO_HZ_FULL=y Kconfig option causes the kernel to avoid sending scheduling-clock interrupts to CPUs with a single runnable task, and such CPUs are said to be "adaptive-ticks CPUs". This is important for applications with aggressive real-time response constraints because it allows them to improve their worst-case response times by the maximum duration of a scheduling-clock interrupt. It is also important for computationally intensive short-iteration workloads: If any CPU is delayed during a given iteration, all the other CPUs will be forced to wait idle while the delayed CPU finishes. Thus, the delay is multiplied by one less than the number of CPUs. In these situations, there is again strong motivation to avoid sending scheduling-clock interrupts. [Test Plan] In order to verify the change will not cause performance issues in context switch we should compare the results for: ./stress-ng --seq 0 --metrics-brief -t 15 Running on a dedicated machine and with the following services disabled: smartd.service, iscsid.service, apport.service, cron.service, anacron.timer, apt-daily.timer, apt-daily-upgrade.timer, fstrim.timer, logrotate.timer, motd-news.timer, man-db.timer. The results didn't show any performance regression: https://kernel.ubuntu.com/~mhcerri/lp1919154/ [Where problems could occur] Performance degradation might happen for workloads with intensive context switching. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1919154/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp