** Changed in: linux (Ubuntu)
Status: In Progress => Fix Released
--
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
** Changed in: linux-lowlatency (Ubuntu Hirsute)
Status: New => Won't Fix
** Changed in: linux-lowlatency (Ubuntu Groovy)
Status: New => Won't Fix
** Changed in: linux-lowlatency (Ubuntu Focal)
Status: New => Won't Fix
--
You received this bug notification because you are
** Changed in: linux (Ubuntu Focal)
Status: In Progress => Won't Fix
** Changed in: linux (Ubuntu Hirsute)
Status: In Progress => Won't Fix
** Changed in: linux (Ubuntu Jammy)
Status: In Progress => Won't Fix
** Changed in: linux (Ubuntu Lunar)
Status: In Progress =>
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
Gerald,
Using gettimeofday for testing the effects of NO_HZ_FULL on context
switch duration may not be measuring anything that changes with regards
to NO_HZ_FULL. gettimeofday is implemented via VDSO, and is not an
actual system call that requires a context switch.
--
You received this bug
Some observations from test results between NO_HZ_FULL built-in but not enable
and default kernel
Tests are from LTP scheduling related under "realtime" category
And there is "no" taskset when running the tests
- Gettimeofday latency (ns basis)
For no_hz_full built-in:
The average is almost the
Another note is that NO_HZ_FULL is already built-in on 6.5 "lowlatency" kernel:
https://bugs.launchpad.net/ubuntu/+source/linux-lowlatency/+bug/2023007
But currently it's only available on Mantic, I think we should also
consider if it's more proper for lowlatency kernel instead of generic
--
The attached is ltp test results with NO_HZ_FULL built-in and activate in
kernel cmdline, e.g.
isolcpus=2-15,18-31 nohz_full=2-15,18-31 rcu_nocbs=2-15,18-31
but tests were run on non-activate CPU 16
** Attachment added: "nohz-log-noisolcpu.tgz"
The attached is ltp test results with NO_HZ_FULL built-in and activate on
kernel cmdline, e.g.
isolcpus=2-15,18-31 nohz_full=2-15,18-31 rcu_nocbs=2-15,18-31
tests were run on cpu 4
** Attachment added: "nohz-log-isolcpu.tgz"
The attached is ltp test results with NO_HZ_FULL built-in but not
actiavte
** Attachment added: "nohz-log.tgz"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1919154/+attachment/5713512/+files/nohz-log.tgz
--
You received this bug notification because you are a member of Kernel
The attached is ltp test results with default ubuntu kernel
** Attachment added: "log.tgz"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1919154/+attachment/5713511/+files/log.tgz
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed
The above tests is based on getpid() system call, which doesn't have
much workload except context switch, so we evaluate the additional
overhead caused by NO_HZ_FULL built-in on AMD EPYC machine
I also used LTP to run scheduler related tests, will attach the test
data later
--
You received this
on 6.2 kernel
With NO_HZ_FULL built-in, the context switch performance is ~4% worse
than default config
--
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
Run some tests with Jammy hwe kernel (6.2.0) on AMD EPYC 7252
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 23703299350 nsec
avg 237 nsec
==> log/notaskset.2 <==
total
Spend some time to get access to AMD EPYC machine
For 5.15 kernel
If we build NO_HZ_FULL into kernel and compare with default kernel (NO_HZ_IDLE)
- on Intel machine, there is no much different
- on Arm64 machine, interestingly, the context switch is a bit faster with
NO_HZ_FULL built-in
- on
On AMD EPYC 7252
Hardware configs:
AMD64
32 CPUs
128G RAM, numa nodes: 2
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
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
Results on Intel machine
Hardware configs:
Dell PowerEdge R730xd
Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
40 CPUs
188G RAM, numa nodes: 2
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)
The attached test code is borrowed from Jay, it measures the average
time for running getpid() 1 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
Test program from Jay
** Attachment added: "syscall-time.c"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1919154/+attachment/5710594/+files/syscall-time.c
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
jammy hwe kernel (6.2) with NO_HZ_FULL:
https://launchpad.net/~gerald-yang-tw/+archive/ubuntu/no-hz-full-6.2
--
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
Since we have some customers need NO_HZ_FULL, I'd like to provide some
updates and progress:
I've borrowed some machines including intel, AMD EPYC, arm64 servers
and now running some tests on a test kernel with
1. CONFIG_NO_HZ_FULL=y
2. not enable nohz_full in kernel cmdline
to evaluate if there
** Also affects: linux (Ubuntu Jammy)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Mantic)
Importance: Undecided
Assignee: Marcelo Cerri (mhcerri)
Status: In Progress
** Also affects: linux (Ubuntu Lunar)
Importance: Undecided
Status: New
The Groovy Gorilla has reached end of life, so this bug will not be
fixed for that release
** Changed in: linux (Ubuntu Groovy)
Status: In Progress => Won't Fix
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://lists.ubuntu.com/archives/kernel-team/2021-April/118905.html
--
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
** Description changed:
[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
Results: https://kernel.ubuntu.com/~mhcerri/lp1919154/
** Changed in: linux (Ubuntu Groovy)
Status: New => In Progress
** Changed in: linux (Ubuntu Focal)
Status: New => In Progress
--
You received this bug notification because you are a member of Kernel
Packages, which is
27 matches
Mail list logo
