Thanks Jay for pointing this out! I just read the man page of vdso, it says gettimeofday is not a real system call and just read the shared memory exports by kernel. It shouldn't be used to measure the user-kernel context switch overhead caused by NO_HZ_FULL.
>From what the tests does, I think scheduling jitter should be more suitable >for measuring the overhead. It measures the time of doing a fixed amount of work multiple times, if there is no additional context-switch overhead, the result should be similar under the same workloads when NO_HZ_FULL is built-in, and I didn't generate any workload on the test machine -- 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
