On Mon, 2020-06-01 at 10:37 -0600, Chris Murphy wrote:
Thanks for the early feedback!
On Mon, Jun 1, 2020 at 7:58 AM Stephen Gallagher <sgallagh(a)redhat.com> wrote:
> * Reading through the Change, you write:
> "using a ZRAM to RAM ratio of 1:2, and capped† to 4GiB" and then you
> talk about examples which are using 50% of RAM as ZRAM. Which is it? A
> ratio of 1:2 implies using 33% of RAM as ZRAM.
This ratio is just a fraction, part of whole, where RAM is the whole.
This convention is used in the zram (package).
Note that /dev/zram0 is a virtual block device, similar to the
'lvcreate -V' option for thin volumes, size is a fantasy. And the ZRAM
device size is not a preallocation of memory. If the compression ratio
2:1 (i.e. 200%) holds, then a ZRAM device sized to 50% of RAM will not
use more than 25% of RAM.
What happen if you can't compress memory at all ?
Will zram use more memory? Or will it simply become useless (but
hopefully harmless) churn ?
I'll try to clear this up somehow; probably avoid using the term
and just go with fraction/percentage. And also note the use of
'zramctl' to see the actual compression ratio.
> * This Change implies the de facto death of hibernation in Fedora.
> Good riddance, IMHO. It never worked safely.
UEFI Secure Boot put us on this path. There's still no acceptable
authenticated encrypted hibernation image scheme, and the SUSE
developer working on it told me a few months ago that the status is
the same as last year and there's no ETA for when he gets the time to
Most people do not use Secure Boot, so this is not really relevant ?
Also having swap on an encrypted dm is not hard, it is just a matter of
plumbing the reboot correctly to unlock the device that needs to be
solved, assuming desktop people are willing to.
Not saying I want to defend hybernate, it is only marginally useful,
and generally fails due to broken drivers anyway, so it is safer to
*not* offer it by default anyway. However it would be nice to make it
straight forward to re-enable it should a user want to and they are on
hw that handles it nicely.
> * Can the upgrade process be made to detect the lack of existing
> and not enable the zswap in that case?
(We're not using zswap at all in this implementation. zram!=zswap -
I expect in the "already has a swap partition" case, no one will
complain about getting a 2nd swap device that's on /dev/zram0, because
it'll just be faster and "spill over" to the bigger swap-on-disk.
The problem though is that it will keep more ram busy, it may cause
OOMs in situation where previously they did not happen. If you have a
fine tuned system that could make a difference, OTOH if you have a fine
tuned system then you are paying attention and can disable zram if you
do not like it.
The problem here would be that it is hard to figure out how to deal
with zram unless you already know about it. I would be easier to deal
with it if disablement required simply to remove an entry from fstab.
It's the use case where "I explicitly did not create a swap
because I hate swap thrashing" that I suspect there may be complaints.
We can't detect that sentiment. All we could do is just decide that no
upgrades get the feature.
or you could decide to get it only if swap is used, and not get it if
no swap is used.
After all if a system has no swap you are not going to make it worse by
not providing zram swap.
You can argue that you *could* make it better in those cases where a
lot of compression can be achieved.
But it is arguably more important to not break existing system than
> Generally, we should probably assume (given existing defaults)
> anyone who has no swap running chose that explicitly and to change it
> would lead to complaints.
But I assert their decision is based on both bad information (wrong
assumptions), and prior bad experience. Even if in the end the
decision is to not apply the feature on upgrades, I think it's worth
some arguing to counter wrong assumptions and bad experiences.
Given that, as you said, you cannot divine intention, you do not know
what intention there was behind a choice.
I run without swap, the reason is that I rather have OOM kick
misbehaving applications fast than have the system trashing on slow
Sure zram does not have the trashing part, probably, because ram is
fast, but it also won't really help a lot, because the problem I have
is runaway processes not just a bit of swap used sometimes. In my case
zram swap will just delay minimally the OOM that is about to come.
You can still argue that in your opinion I should use zram swap, but it
is a matter of opinions and you have less data about my system and how
I use it than I do. So, sure it is arguable in many case, but yo can't
argue, so you should take the defensive approach and respect user
choices. They can easily systemctl their way into enabling zram swap if
> * If you're going to do the Supplements:, you need to do
> fedora-release-common` or you won't get everyone. The `fedora-release`
> package is for non-Edition/Spin installs.
I suggest these three lines in the configuration (I've updated the
change proposal how to test section to include this):
memory-limit = none
zram-fraction = 0.5
Does this mean zram is going to use potentially half of the available
system ram ?
There is no cap functionality yet in the generator.
server mailing list -- server(a)lists.fedoraproject.org
To unsubscribe send an email to server-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
RHEL Crypto Team
Red Hat, Inc