Thanks for the early feedback!
On Mon, Jun 1, 2020 at 7:58 AM Stephen Gallagher sgallagh@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.
I'll try to clear this up somehow; probably avoid using the term ratio 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 revisit it.
- Can the upgrade process be made to detect the lack of existing swap
and not enable the zswap in that case?
(We're not using zswap at all in this implementation. zram!=zswap - easy mistake.)
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.
It's the use case where "I explicitly did not create a swap device 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.
Generally, we should probably assume (given existing defaults) that anyone who has no swap running chose that explicitly and to change it would lead to complaints.
Perhaps.
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.
- If you're going to do the Supplements:, you need to do `Supplements:
fedora-release-common` or you won't get everyone. The `fedora-release` package is for non-Edition/Spin installs.
Right. Fixed.
I suggest these three lines in the configuration (I've updated the change proposal how to test section to include this):
[zram0] memory-limit = none zram-fraction = 0.5
There is no cap functionality yet in the generator.
-- Chris Murphy
I joined this list because I'm interested in learning more about the specific requirements and features of cloud images.
So I'm wondering what ZRAM adds or what problem ZRAM solves for a cloud image?
Thanks
On Tue, 2 Jun 2020, 02:38 Chris Murphy lists@colorremedies.com wrote:
Thanks for the early feedback!
On Mon, Jun 1, 2020 at 7:58 AM Stephen Gallagher sgallagh@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.
I'll try to clear this up somehow; probably avoid using the term ratio 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 revisit it.
- Can the upgrade process be made to detect the lack of existing swap
and not enable the zswap in that case?
(We're not using zswap at all in this implementation. zram!=zswap - easy mistake.)
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.
It's the use case where "I explicitly did not create a swap device 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.
Generally, we should probably assume (given existing defaults) that anyone who has no swap running chose that explicitly and to change it would lead to complaints.
Perhaps.
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.
- If you're going to do the Supplements:, you need to do `Supplements:
fedora-release-common` or you won't get everyone. The `fedora-release` package is for non-Edition/Spin installs.
Right. Fixed.
I suggest these three lines in the configuration (I've updated the change proposal how to test section to include this):
[zram0] memory-limit = none zram-fraction = 0.5
There is no cap functionality yet in the generator.
-- Chris Murphy _______________________________________________ cloud mailing list -- cloud@lists.fedoraproject.org To unsubscribe send an email to cloud-leave@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 List Archives: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org
On Mon, Jun 1, 2020 at 2:55 PM Michael Hall mike@mjhall.org wrote:
I joined this list because I'm interested in learning more about the specific requirements and features of cloud images.
So I'm wondering what ZRAM adds or what problem ZRAM solves for a cloud image?
Simplest answer: better utilization of a limited resource, memory.
It does this by making it possible for the kernel to evict anonymous pages. Therefore avoiding repetitive reclaiming of file pages when under any sort of memory pressure. And it's faster than swap to disk. And since it doesn't require a preallocation, if the workload were to never need swap, it has a nearly zero cost. If you aren't using some swap, aren't you in a sense overprovisioning memory?