I recently stumbled over the 300 HZ option in the kernel
configuration. Currently we are using 250 HZ with IDLE_HZ. The HZ
setting is used
as far as I can see to determine when jiffies are advancing, so it
influences the granularity of a couple of things like kvmclock, timers
and so on. Also
USER_HZ is 100 HZ which is the granularity to which some metrics are
exported to user space. 300 is divisible without remainder by 100,
so it appears there are good reasons for switching the default, and it
is "just" 20% more timer interrupts than before, so it should not be a
huge issue. I also
did a test build and a 300 HZ kernel is by a few bytes smaller than a
250 HZ kernel, indicating that the compiler can optimize away a few
I am seeing an increase in a few small functions, and I'm looking into
making the code size increase go away with a source level tweak. I've
benchmarked both versions in a micro
benchmark that does a billion invocations of both, and while the code
is larger, it runs in exactly the same runtime (+/- 3% which I
consider my benchmark noise level) on a Ryzen Zen 2+.
In the Kconfig description of 300 HZ option, it appears this is more
recommended for multimedia usecases because it is divisible without
remainder for common rates, like 30 (fps), 60 fps , 120 fps, 44.1khZ
and others that are often needed.
This is imho not only usable for desktop, but also for servers that
are using multimedia related applications.
I've seen that fedora-like distributions use 1000 HZ, arch linux uses
300 Hz and debian defaults to 250 HZ. So there is no clear trend. I'd
be fine with 300 or 1000 HZ.
Comments? Would like to hear your feedback before sending a change to
the Tumbleweed configs.
I use $SUBJECT on my Leap systems which utilize newer hardware than what
is supported by the standard Leap kernel. This used to work up until
version 5.16.9-lp153.4.1.gdedbf20, but stopped afterwards. The gcc
version in that project obviously needs its own gcc11 which doesn't
$ osc buildinfo Kernel:stable:Backport kernel-default standard x86_64
<buildinfo project="Kernel:stable:Backport" repository="standard" package="kernel-default" downloadurl="https://download.opensuse.org/repositories">
<error>unresolvable: nothing provides gcc11-PIE needed by gcc-PIE</error>
Is this project still supposed to work for Leap users who need a newer
If I run cat /boot/config-5.16.1-1-default | grep -i swap
It returns CONFIG_ZSWAP=Y
So the kernel supports zswap but it is currently NOT enabled.
When system is booted the following journal message appears
kernel: zswap: loaded using pool lzo/zbud
ps aux | grep -i zswap
root 135 0.0 0.0 0 0 ? I< Feb09 0:00 [zswap-shrink]
If zswap is NOT enabled, why is zswap loaded with a pool at boot time and why is the
zswap-shrink process running?
I find that the same situation on a TW test machine I have that is running the 22.214.171.124 kernel so it is not an isolated case.
Is this a bug?
Am 12.02.22 um 17:07 schrieb Joe Salmeri:
> cat /boot/config-5.16.1-1-default | grep -i swap
> returns CONFIG_ZSWAP=Y
> cat /sys/module/zswap/parameters/enabled
> returns N
> So the kernel supports zswap but it is currently NOT enabled.
> When system is booted the following journal message appears
> kernel: zswap: loaded using pool lzo/zbud
> ps aux | grep -i zswap
> root 135 0.0 0.0 0 0 ? I< Feb09 0:00 [zswap-shrink]
> If zswap is NOT enabled, why is zswap loaded with a pool at boot time and why is the
> zswap-shrink process running?
> I find that the same situation on a TW test machine I have that is running the 126.96.36.199 kernel so it is not an isolated case.
> Is this a bug?
Maybe kernel(a)lists.opensuse.org is more appropriate (cc'ing).
I just found that I could not do "dmesg" as normal user in a Leap 15.3
installation. I'm used to be able to do this from my Factory machines.
Investigation showed, that Leap's kernel sets
CONFIG_SECURITY_DMESG_RESTRICT=y while the Factory kernel (at least
kernel-vanilla and kernel-default from Kernel:HEAD) does not.
I do not care which default is chosen, but for consistency I'd suggest
to settle for one of the two possible options ;-)
"For a successful technology, reality must take precedence over
public relations, for nature cannot be fooled." -- Richard Feynman