Your message dated Thu, 01 May 2025 14:41:28 +0200 (CEST)
with message-id <20250501124128.293f8be2...@eldamar.lan>
and subject line Closing this bug (BTS maintenance for src:linux bugs)
has caused the Debian Bug report #972709,
regarding Wishlist/RFC: Change to CONFIG_PREEMPT_NONE in linux-image-cloud-*
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
972709: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972709
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: linux-image-cloud-amd64
Version: 4.19+105+deb10u7
Severity: wishlist
Since cloud images are mostly run for server workloads in headless
environments accessed via network only, it would be better if
"linux-image-cloud-*" kernels were compiled with CONFIG_PREEMPT_NONE=y
("No Forced Preemption (Server)").
Currently those packages use CONFIG_PREEMPT_VOLUNTARY=y ("Voluntary
Kernel Preemption (Desktop)")
CONFIG_PREEMPT_NONE description from kernel help:
"This is the traditional Linux preemption model, geared towards
throughput. It will still provide good latencies most of the time,
but there are no guarantees and occasional longer delays are
possible.
Select this option if you are building a kernel for a server
or scientific/computation system, or if you want to maximize the
raw processing power of the kernel, irrespective of scheduling
latencies."
Help on CONFIG_PREEMPT_VOLUNTARY:
"This option reduces the latency of the kernel by adding more
"explicit preemption points" to the kernel code. These new
preemption points have been selected to reduce the maximum latency
of rescheduling, providing faster application reactions, at the cost
of slightly lower throughput.
This allows reaction to interactive events by allowing a low
priority process to voluntarily preempt itself even if it is in
kernel mode executing a system call. This allows applications to run
more 'smoothly' even when the system is under load.
Select this if you are building a kernel for a desktop system.
In other words, choosing CONFIG_PREEMPT_NONE would favour throughput
over latency, the latter being more important on GUI environment (where
a non-responsive mouse is bad, for example) but not on servers.
A second benefit of CONFIG_PREEMPT_NONE is that it reduces context
switch overhead, which means more CPU cycles are available for doing
useful computing. This is specially important on virtualized
environments and/or guest scheduling is based on CPU "credits" (for
example, AWS).
--
FV
--- End Message ---
--- Begin Message ---
Hi
This bug was filed for a (very) old kernel or the bug is old itself
without resolution. Maybe it was for a feature enablement which nobody
acted on. We are sorry we were not able to timely deal with this issue.
There are many open bugs for the src:linux package and thus we are
closing older bugs where it's unclear if they still occur in newer
versions and are still relevant to the reporter. For an overview see:
https://bugs.debian.org/src:linux .
If you can reproduce your issue with
- the current version in unstable/testing
- the latest kernel from backports
or, if it was a feature addition/wishlist and still consider it
relevant, then:
Please reopen the bug, see https://www.debian.org/Bugs/server-control
for details.
Please try to provide as much fresh details including kernel logs where
relevant. In particular were an issue is coupled with specific hardware we
might ask you to do additional debugging on your side as the owner of the
hardware.
Regards,
Salvatore
--- End Message ---
