This bug is awaiting verification that the linux-nvidia-
tegra/6.8.0-1001.1 kernel in -proposed solves the problem. Please test
the kernel and update this bug with the results. If the problem is
solved, change the tag 'verification-needed-noble-linux-nvidia-tegra' to
'verification-done-noble-linux-
This bug was fixed in the package linux - 6.8.0-20.20
---
linux (6.8.0-20.20) noble; urgency=medium
* noble/linux: 6.8.0-20.20 -proposed tracker (LP: #2058221)
* Noble update: v6.8.1 upstream stable release (LP: #2058224)
- x86/mmio: Disable KVM mitigation when X86_FEATURE_CL
** Changed in: linux (Ubuntu Noble)
Status: New => Fix Committed
--
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/2051342
Title:
Enable lowlatency settings in the generic kernel
St
@turner basically any type of I/O workload can benefit from the HZ=1000
change, I haven't posted any test result, because in the scope of this
proposal I wanted to focus mainly at the regression potential for CPU-
intensive workloads and the benefits in terms of power consumption (this
one as a pos
I haven’t spotted any tests that show a workload with a significant
improvement shown here, on discourse, or Phoronix. Am I incorrect?
Please keep in mind that I’m not suggesting that this initiative not
move forward as there appears to be plenty of evidence being built up
suggesting that there is
More tests and results available here:
https://discourse.ubuntu.com/t/enable-low-latency-features-in-the-
generic-ubuntu-kernel-for-24-04/42255
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bug
@andysem yes that is also another possibility. The idea is to do a lot
of tests and if we find that there's a remote possibility to introduce
significant performance regressions in certain cases we can still keep
HZ=250, but definitely go with the other options.
--
You received this bug notificat
@arighi: Did you consider applying lowlatency settings to generic kernel
but keeping CONFIG_HZ=250?
I suspect, the majority of desktop usage issues (i.e. responsiveness)
would be solved by `preempt=full rcu_nocbs=all` being the default (or
whatever the equivalent boot options are). While keeping C
I redid the Phoronix Stress-NG 0.16.04: Socket Activity test, the one
that showed such a dramatic difference in their test. I increased to
number of test runs from 3 to 10 and time per run from 30 to 60 seconds.
I got:
250Hz kernel (generic): 6608.74 Bogo Op/s, Deviation 0.56%
1000Hz kernel (lowla
The generic Ubuntu kernel has dynamic preempt enabled. This allows the
preemption model to be changed at runtime between: none, voluntary (the
default), and full.
It would be super interesting to test what impact this has for latency
sensitive workloads, and whether this can help you make the low
While testing locally, I have found this problem:
https://bugs.launchpad.net/ubuntu/+source/linux-signed-lowlatency-
hwe-6.5/+bug/2051733
If this is indeed a valid bug and not something weirdly specific to my
system, I'd say `nohz_full` is non-functional.
--
You received this bug notification be
For the Stress-NG 0.16.04: pts/stress-ng-1.11.0 [Test: Socket Activity]
I get:
6633.31 Bogo Ops/s on a 1000Hz kernel. 0.9% improvement.
6572.92 Bogo Ops/s on a 250 Hz kernel.
I did this in a hurry, and will re-test tonight or tomorrow.
--
You received this bug notification because you are a mem
@andysem correct, without `nohz_full` specified at boot
CONFIG_NO_HZ_FULL has no effect, except for the little extra overhead
that it's adding to the tick handler (there is still some overhead with
this option enabled, even if it's not used). That's why I'd like to
measure the time spent in some of
I couldn't find this in the benchmark description on Phoronix, so I'm
assuming the lowlatency kernel was booted with default parameters. Which
means CONFIG_NO_HZ_FULL basically had no effect. This is probably fair
for most users who won't specify `nohz_full` kernel parameter and will
observe the pe
@colin-king noticed, I just left a thank you message in the article.
I'll still do the tests, but it's nice to see that someone else is
contributing to this!
Another thing that I'd like to measure is to bpftrace the time spent in
the tick handler before and after these changes applied, because we
Looks like Michael Larabel has done some analysis for you already :-)
https://www.phoronix.com/news/Ubuntu-Generic-LL-Kernel
--
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/2051342
Title:
@Andrea, that's a good start, but it may be worth running some of the
Phoronix Tests too as they are a good spread of use cases.
--
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/2051342
Titl
@colin-king thanks! Any suggestion in particular? I was thinking to
lmbench, netperf and fio.
--
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/2051342
Title:
Enable lowlatency settings in
@dsmythies thank you so much for sharing the results of your tests,
really useful info!
I'm planning to do more tests setting the performance governor, I've
been doing my initial tests only with the default Ubuntu settings, that
means with the "Balanced" power mode enabled (that I think it's using
It may be worth trying a wider range of synthetic benchmarks to see how
it affects scheduling, I/O, RCU and power consumption.
--
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/2051342
Title:
Before my post yesterday, I had never used the stress-ng utility, and
only did so to repeat the originally posted test case. However, there
was run to run variability with the stress-ng test that I could not
understand for a 100% user, 0% system, type program. I decided to retest
using one my own C
I found this bug report by accident, while searching for something else.
I pretty much only use mainline kernels and only 1000 Hertz.
I support this proposed default Ubuntu kernel configuration change.
The tick ISR is incredibly efficient (less than 2 uSec on my test
system), and I do not understa
** Description changed:
[Impact]
Ubuntu provides the "lowlatency" kernel: a kernel optimized for
applications that have special "low latency" requirements.
Currently, this kernel does not include any specific UBUNTU SAUCE
patches to improve the extra "low latency" requirements, but
** Description changed:
[Impact]
Ubuntu provides the "lowlatency" kernel: a kernel optimized for
applications that have special "low latency" requirements.
Currently, this kernel does not include any specific UBUNTU SAUCE
patches to improve the extra "low latency" requirements, but
** Description changed:
[Impact]
Ubuntu provides the "lowlatency" kernel: a kernel optimized for
applications that have special "low latency" requirements.
Currently, this kernel does not include any specific UBUNTU SAUCE
patches to improve the extra "low latency" requirements, but
** Description changed:
[Impact]
Ubuntu provides the "lowlatency" kernel: a kernel optimized for
applications that have special "low latency" requirements.
Currently, this kernel does not include any specific UBUNTU SAUCE
patches to improve the extra "low latency" requirements, but
26 matches
Mail list logo