On arm64 machine Hardware configs: Aarch64 128 CPUs 502G RAM, numa nodes: 4
Software configs: OS: ubuntu 20.04 Official kernel: 5.15 hwe (5.15.0-86.96~20.04.1) Test kernel: 5.15 hwe (5.15.0-86.96~20.04.1+test20231013b0) https://launchpad.net/~gerald-yang-tw/+archive/ubuntu/focal-no-hz-full Test case 1, without NO_HZ_FULL built-in (default ubuntu kernel config): Run test program 4 times without taskset tail -n 2 log/notaskset.* ==> log/notaskset.1 <== total 29370767905 nsec avg 293 nsec ==> log/notaskset.2 <== total 29359558119 nsec avg 293 nsec ==> log/notaskset.3 <== total 29370043654 nsec avg 293 nsec ==> log/notaskset.4 <== total 29362365433 nsec avg 293 nsec Run test program 4 times with taskset to CPU 4 tail -n 2 log/taskset.* ==> log/taskset.1 <== total 29372156600 nsec avg 293 nsec ==> log/taskset.2 <== total 29367538079 nsec avg 293 nsec ==> log/taskset.3 <== total 29366224367 nsec avg 293 nsec ==> log/taskset.4 <== total 29367978392 nsec avg 293 nsec Test case 2, with NO_HZ_FULL built-in but not activate in kernel cmdline: Run test program 4 times without taskset tail -n 2 nohz-log/notaskset.* ==> nohz-log/notaskset.1 <== total 27591230003 nsec avg 275 nsec ==> nohz-log/notaskset.2 <== total 27582359987 nsec avg 275 nsec ==> nohz-log/notaskset.3 <== total 27585635138 nsec avg 275 nsec ==> nohz-log/notaskset.4 <== total 27587532170 nsec avg 275 nsec Run test program 4 times with taskset to CPU 4 tail -n 2 nohz-log/taskset.* ==> nohz-log/taskset.1 <== total 27587206878 nsec avg 275 nsec ==> nohz-log/taskset.2 <== total 27579854104 nsec avg 275 nsec ==> nohz-log/taskset.3 <== total 27588163798 nsec avg 275 nsec ==> nohz-log/taskset.4 <== total 27589441746 nsec avg 275 nsec Test case 3, with NO_HZ_FULL built-in, activate nohz_full in kernel cmdline: cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-5.15.0-86-generic root=UUID=7c25ee2a-4c18-462a-90db-94273e5de74b ro isolcpus=2-63,66-127 nohz_full=2-63,66-127 rcu_nocbs=2-63,66-127 sysrq_always_enabled Run test program 4 times without taskset tail -n 2 nohz-activate-log/notaskset.* ==> nohz-activate-log/notaskset.1 <== total 29986516050 nsec avg 299 nsec ==> nohz-activate-log/notaskset.2 <== total 29982386090 nsec avg 299 nsec ==> nohz-activate-log/notaskset.3 <== total 29976017400 nsec avg 299 nsec ==> nohz-activate-log/notaskset.4 <== total 29977079348 nsec avg 299 nsec Run test program 4 times with taskset to CPU 4 tail -n 2 nohz-activate-log/taskset.* ==> nohz-activate-log/taskset.1 <== total 40561421305 nsec avg 405 nsec ==> nohz-activate-log/taskset.2 <== total 40556501183 nsec avg 405 nsec ==> nohz-activate-log/taskset.3 <== total 40554876491 nsec avg 405 nsec ==> nohz-activate-log/taskset.4 <== total 40554776851 nsec avg 405 nsec Test case 4, with NO_HZ_FULL built-in, activate nohz_full in kernel cmdline, but run on non-activate CPU: Run test program on non-activate nohz_full CPU 64 tail -n 2 nohz-activate-off-log/* ==> nohz-activate-off-log/taskset.1 <== total 29980106645 nsec avg 299 nsec ==> nohz-activate-off-log/taskset.2 <== total 29982445376 nsec avg 299 nsec ==> nohz-activate-off-log/taskset.3 <== total 29973087899 nsec avg 299 nsec ==> nohz-activate-off-log/taskset.4 <== total 29982214675 nsec avg 299 nsec -- 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
