Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)
On Wed, Jan 20, 2021 at 10:59:52AM -0800, Samuel Sieb wrote: > That's about changing settings. When restarting the zram service, > it has to remove the swap device which forces all the swapped pages > back into RAM. This might not be successful if you don't have > enough RAM, so if you are using a low memory device, you should > reboot instead. Although if you see that you aren't using too much > swap, then it could be ok. Thanks! That makes sense! -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)
On 1/20/21 8:14 AM, Matthew Miller wrote: On Sun, Jan 17, 2021 at 05:58:45PM +, Zbigniew Jędrzejewski-Szmek wrote: Someone on Fedora Discussion¹ noticed this number and wonders if it's meant to be 8192. Not that it probably matters very much, but, you know, nice round numbers and all. Yep, it was. I'll fix the wiki. On another note, someone asked what "(Note that the device is destroyed and recreated during restart. This means that all pages will be "swapped in", i.e. decompressed. On machines with low memory, rebooting might be a better option.)" means, and I realized I actually have no idea. Does this mean that low memory machines should reboot often? Or is this just about testing after changing settings? That's about changing settings. When restarting the zram service, it has to remove the swap device which forces all the swapped pages back into RAM. This might not be successful if you don't have enough RAM, so if you are using a low memory device, you should reboot instead. Although if you see that you aren't using too much swap, then it could be ok. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)
On Sun, Jan 17, 2021 at 05:58:45PM +, Zbigniew Jędrzejewski-Szmek wrote: > > Someone on Fedora Discussion¹ noticed this number and wonders if it's meant > > to be 8192. Not that it probably matters very much, but, you know, nice > > round numbers and all. > > Yep, it was. I'll fix the wiki. On another note, someone asked what "(Note that the device is destroyed and recreated during restart. This means that all pages will be "swapped in", i.e. decompressed. On machines with low memory, rebooting might be a better option.)" means, and I realized I actually have no idea. Does this mean that low memory machines should reboot often? Or is this just about testing after changing settings? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)
On Sun, Jan 17, 2021 at 12:28:10PM -0500, Matthew Miller wrote: > On Mon, Jan 11, 2021 at 11:50:03AM -0500, Ben Cotton wrote: > > == Scope == > > * Proposal owners: change the defaults in `zram-generator-defaults` > > package to `zram-fraction=1.0`, `max-zram-size=8096`. > > Someone on Fedora Discussion¹ noticed this number and wonders if it's meant > to be 8192. Not that it probably matters very much, but, you know, nice > round numbers and all. Yep, it was. I'll fix the wiki. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)
On Mon, Jan 11, 2021 at 11:50:03AM -0500, Ben Cotton wrote: > == Scope == > * Proposal owners: change the defaults in `zram-generator-defaults` > package to `zram-fraction=1.0`, `max-zram-size=8096`. Someone on Fedora Discussion¹ noticed this number and wonders if it's meant to be 8192. Not that it probably matters very much, but, you know, nice round numbers and all. (1. https://discussion.fedoraproject.org/t/fedora-program-update-2021-02/26034/2?u=mattdm) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)
On Tue, Jan 12, 2021 at 04:58:36PM +0100, Vitaly Zaitsev via devel wrote: > On 11.01.2021 21:55, ElXreno wrote: > >Also, other data (video editors, for example) which are not > >compressible can get into RAM. > > Windows guests running under KVM/qemu too. > > Windows 10 uses its own build-in memory compression and > deduplication service. Yeah, but is this a realistic problem? If you create a VM for which you allocate more memory than available RAM, as soon as the guest utilizes this allocation in full, the host will be unusable, with or without zram... Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)
It seems I was wrong. I did the same test again, and this time even with more `zram-fraction'. The Darktable memory is compressed, there was no more hang-up problem. Sorry about the noise, maybe it was a regression in the old kernel, or my configuration error somewhere. On 1/12/21 5:55 PM, Matthew Miller wrote: Is this actually incompressible, though? Sure, a compressed TIFF would be, but isn't the raw bitmap loaded into memory likely quite compressible? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)
Some tests: https://youtu.be/d4Sc80TMEtA webkit2gtk3 compilation with zram-fraction=1, max-zram-size=8192 Physical RAM: 8GB. Kernel 5.10.6 Fedora 33, with such deviations from default: - zram-fraction=1, max-zram-size=8192 (this is default for f34) - le9 patch - https://github.com/hakavlad/le9-patch GPU heavily loaded for all time in test at 100% and almost all VRAM utilized. Software which run in background during test: - Firefox with many open tabs - OBS - virt-manager and guest Fedora 33 - Steam - Telegram No hangs, no heavily freezes, system was responsive for all time during webkit2gtk3 compilation. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)
> system hangs with earlyoom and swap on zram, disksize=150% MemTotal, compression ratio at the end is 1.4, SwapFree=25%, the zram device occupies 80% of the memory with running Blender https://imgur.com/a/wNvBVIn. > With disksize=100% MemTotal this should be very rare case. -- https://pagure.io/fedora-workstation/issue/127#comment-629519 > Scaling ZRAM to full memory size +1, in most cases it should make sense. вт, 12 янв. 2021 г. в 01:50, Ben Cotton : > https://fedoraproject.org/wiki/Changes/Scale_ZRAM_to_full_memory_size > > > == Summary == > Fedora 33 [[Changes/SwapOnZRAM|enabled zram by default]]. The size of > the virtual swap devices was set so that the amount of memory used for > compressed swap pages was limited to a quarter of physical memory in > typical scenarios. That size is now increased to half of physical > memory (`zram-fraction` becomes 1.0, `max-zram-size` becomes 8 GiB). > This allows systems with small amounts to successfully launch the > [https://anaconda-installer.readthedocs.io/en/latest/ Anaconda > installer] and other programs. > > == Owner == > > * Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]] > * Email: zbys...@in.waw.pl > * Name: [[User:jwrdegoede|Hans de Goede]] > * Email: hdego...@redhat.com > > > == Detailed Description == > > When ZRAM was enabled by default in Fedora 33, the size of the device > (before compression) was limited to fraction 0.5 of RAM or 4 GiB, > whichever is less. The reason to limit the fraction to less than 1.0 > is that with only incompressible data in memory, whole RAM would be > filled by the "compressed" pages, leaving no RAM for normal use. But > this concern seems to have been overblown, and there have been no > reports of compressed swap taking up too much memory. In real use, we > will have at least a few hundred MiB of code in memory, which > compresses quite well, so some compression will occur even when > working with incompressible data. In typical usage scenarios, we get > effective compression of 2:1 or 3:1, which means that the compressed > pages use at most between 1/4th and 1/6th of RAM. By increasing the > fraction to 1.0, we expect to consign up to half of RAM for compressed > pages. > > Increasing the size of the device is important for small devices. For > devices with 1GB of RAM, sizing ZRAM to 1 GiB allows successful > installation with Anaconda. In general, it is expected that having > more compressed swap will make the device more functional after > installation too. This increase is the most important for devices with > small amounts of memory (< 1 GiB), but will be beneficial to systems > with slightly larger systems (1–8 GiB). > > Technically, this change is completely trivial, amounting to two lines > of configuration. Nevertheless, there is some potential for problems > with incompressible workloads. The experience with ZRAM so far makes > the Change authors optimistic that no issues will be encountered, but > users and other developers should be aware of the change. > > > == Benefit to Fedora == > > Fedora works better on devices with low RAM. In particular, the > installer can function. > > == Scope == > * Proposal owners: change the defaults in `zram-generator-defaults` > package to `zram-fraction=1.0`, `max-zram-size=8096`. > > * Other developers: N/A (not a System Wide Change) > * Policies and guidelines: N/A (not a System Wide Change) > * Trademark approval: N/A (not needed for this Change) > > > == Upgrade/compatibility impact == > Default configuration is changed. Systems with local configuration > will not be affected. Systems which had zram-generator disabled will > not be affected. > > == How To Test == > Install the new version of the `zram-generator-defaults` package, > execute `sudo systemctl daemon-reload && sudo systemctl restart > swap-create@zram0`, use `zramctl` to check that the device has the > expected size. After some use, check that pages are compressed at > least with ration 2:1: > > $ zramctl > NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT > /dev/zram0 lzo-rle 7.6G 4K 74B 12K 4 [SWAP] > ^ ^^ > |\\___ the ratio of those > values should be more than 2:1 > | > `-- this should be approx the size of RAM > > (Note that the device is destroyed and recreated during restart. This > means that all pages will be "swapped in", i.e. decompressed. On > machines with low memory, rebooting might be a better option.) > > == User Experience == > Not user visible. > > == Dependencies == > None. > > == Contingency Plan == > * Contingency mechanism: Revert default configuration to previous values. > * Contingency deadline: Final freeze, any time really. > * Blocks release? No > * Blocks product? No > > == Documentation == > None. > > == Release Notes == > The default size of compressed zram devices (`/dev/zram0`) has been > increased to 1.0
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)
On 11.01.2021 21:55, ElXreno wrote: Also, other data (video editors, for example) which are not compressible can get into RAM. Windows guests running under KVM/qemu too. Windows 10 uses its own build-in memory compression and deduplication service. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)
On Tue, Jan 12, 2021 at 4:06 AM Chris Murphy wrote: > > On Mon, Jan 11, 2021 at 1:55 PM ElXreno wrote: > > > I think it's a bad idea. It is better to make `zram-fraction` equal to > > 0.8 or 0.9, but not 1.0. > > Just to clarify. zram-fraction 1.0 means the zram *device size* will > be equal to RAM, capped at 8G. The actual amount of memory used is > zero, until the kernel starts to evict dirty pages to swap, where they > are then compressed. And the maximum amount of RAM due to compression > would be predicated on compression ratio. If we assume a conservative > 2:1 ratio (compression results in 50% of original size), the max ram > would be the lesser of 4G or 50% of RAM. For reference this is the config we ran on Fedora arm with the zram package for a number of releases before F-33 and the new tool tool over and we had few reports of issues with this factor even with devices with a small amount of real memeory so I have no concerns, in fact it just gets us back to what we had there by default in F-32. > Does this reduce your concern? > > 80% might still be reasonable, and still pretty conservative. > > > For example, if you run Darktable, load a floating-point TIFF image into > > it, and try to export it, on systems with little RAM, it will fill both > > RAM itself and zram, and cause the system to freeze completely because > > the memory is almost incompressible. > > Also, other data (video editors, for example) which are not compressible > > can get into RAM. > > Are you sure that this data is compressed in memory as well as the > on-disk encoding? The editing operations themselves surely operate on > uncompressed data, and then it's compressed upon being written to > disk. > > -- > Chris Murphy > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)
On Mon, Jan 11, 2021 at 11:55:12PM +0300, ElXreno wrote: > For example, if you run Darktable, load a floating-point TIFF image > into it, and try to export it, on systems with little RAM, it will > fill both RAM itself and zram, and cause the system to freeze > completely because the memory is almost incompressible. Is this actually incompressible, though? Sure, a compressed TIFF would be, but isn't the raw bitmap loaded into memory likely quite compressible? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)
Different question: This sounds like you're handling data that won't fit into RAM+Swap anyway, using zram isn't going to help (or hurt), because with or without compression, your data just doesn't fit in memory. I'm talking about possible outcomes, including the ones I've had. What does the maximum fraction of zram have to do with that? Either way, this sounds like you just don't have enough physical RAM for your workload. In that case, adding physical swap (on disk) is probably the only way to make that work (other than buying more RAM). `zram-fraction = 1`. Yes, I have not enough memory, but even on systems with a large amount of RAM, it is possible what I described earlier. In most cases, of course, with a zram-fraction that equals one (or even more) the system will run stable, but just keep in mind that where data may not be compressed, there may be problems. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)
On Mon, Jan 11, 2021 at 9:55 PM ElXreno wrote: > > I apologize for the possible duplicate message, the past didn't show up > for reasons I don't understand. > > I think it's a bad idea. It is better to make `zram-fraction` equal to > 0.8 or 0.9, but not 1.0. > For example, if you run Darktable, load a floating-point TIFF image into > it, and try to export it, on systems with little RAM, it will fill both > RAM itself and zram, and cause the system to freeze completely because > the memory is almost incompressible. > Also, other data (video editors, for example) which are not compressible > can get into RAM. Different question: This sounds like you're handling data that won't fit into RAM+Swap anyway, using zram isn't going to help (or hurt), because with or without compression, your data just doesn't fit in memory. What does the maximum fraction of zram have to do with that? Either way, this sounds like you just don't have enough physical RAM for your workload. In that case, adding physical swap (on disk) is probably the only way to make that work (other than buying more RAM). Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)
Is earlyoom disabled on this system? It should send SIGTERM to something in this case - which is not the best UX as a hint that an adjustment needs to be made. But I want to make sure there isn't something else going wrong. Yes, it's off. And I have an assumption that earlyoom may not have time to work if there is a lot of pressure on the memory. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)
On Tue, Jan 12, 2021 at 12:14 AM ElXreno wrote: > > > Does this reduce your concern? > In a way, yes. Most of the time memory will be compressible, I agree, > but there are non-compressible data, and I'm only concerned about that. > > In my opinion, it's better not to set the zram size to 100% for > everyone. Whoever is sure that their data will be compressible can set > it to 100%. > > > Are you sure that this data is compressed in memory as well as the > > on-disk encoding? The editing operations themselves surely operate on > > uncompressed data, and then it's compressed upon being written to > > disk. > I'm not sure. But I've had a few times where zram didn't compress > anything and ended up freezing the system completely. Is earlyoom disabled on this system? It should send SIGTERM to something in this case - which is not the best UX as a hint that an adjustment needs to be made. But I want to make sure there isn't something else going wrong. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)
Does this reduce your concern? In a way, yes. Most of the time memory will be compressible, I agree, but there are non-compressible data, and I'm only concerned about that. In my opinion, it's better not to set the zram size to 100% for everyone. Whoever is sure that their data will be compressible can set it to 100%. Are you sure that this data is compressed in memory as well as the on-disk encoding? The editing operations themselves surely operate on uncompressed data, and then it's compressed upon being written to disk. I'm not sure. But I've had a few times where zram didn't compress anything and ended up freezing the system completely. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)
On Mon, Jan 11, 2021 at 1:55 PM ElXreno wrote: > I think it's a bad idea. It is better to make `zram-fraction` equal to > 0.8 or 0.9, but not 1.0. Just to clarify. zram-fraction 1.0 means the zram *device size* will be equal to RAM, capped at 8G. The actual amount of memory used is zero, until the kernel starts to evict dirty pages to swap, where they are then compressed. And the maximum amount of RAM due to compression would be predicated on compression ratio. If we assume a conservative 2:1 ratio (compression results in 50% of original size), the max ram would be the lesser of 4G or 50% of RAM. Does this reduce your concern? 80% might still be reasonable, and still pretty conservative. > For example, if you run Darktable, load a floating-point TIFF image into > it, and try to export it, on systems with little RAM, it will fill both > RAM itself and zram, and cause the system to freeze completely because > the memory is almost incompressible. > Also, other data (video editors, for example) which are not compressible > can get into RAM. Are you sure that this data is compressed in memory as well as the on-disk encoding? The editing operations themselves surely operate on uncompressed data, and then it's compressed upon being written to disk. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)
I apologize for the possible duplicate message, the past didn't show up for reasons I don't understand. I think it's a bad idea. It is better to make `zram-fraction` equal to 0.8 or 0.9, but not 1.0. For example, if you run Darktable, load a floating-point TIFF image into it, and try to export it, on systems with little RAM, it will fill both RAM itself and zram, and cause the system to freeze completely because the memory is almost incompressible. Also, other data (video editors, for example) which are not compressible can get into RAM. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Scale_ZRAM_to_full_memory_size == Summary == Fedora 33 [[Changes/SwapOnZRAM|enabled zram by default]]. The size of the virtual swap devices was set so that the amount of memory used for compressed swap pages was limited to a quarter of physical memory in typical scenarios. That size is now increased to half of physical memory (`zram-fraction` becomes 1.0, `max-zram-size` becomes 8 GiB). This allows systems with small amounts to successfully launch the [https://anaconda-installer.readthedocs.io/en/latest/ Anaconda installer] and other programs. == Owner == * Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]] * Email: zbys...@in.waw.pl * Name: [[User:jwrdegoede|Hans de Goede]] * Email: hdego...@redhat.com == Detailed Description == When ZRAM was enabled by default in Fedora 33, the size of the device (before compression) was limited to fraction 0.5 of RAM or 4 GiB, whichever is less. The reason to limit the fraction to less than 1.0 is that with only incompressible data in memory, whole RAM would be filled by the "compressed" pages, leaving no RAM for normal use. But this concern seems to have been overblown, and there have been no reports of compressed swap taking up too much memory. In real use, we will have at least a few hundred MiB of code in memory, which compresses quite well, so some compression will occur even when working with incompressible data. In typical usage scenarios, we get effective compression of 2:1 or 3:1, which means that the compressed pages use at most between 1/4th and 1/6th of RAM. By increasing the fraction to 1.0, we expect to consign up to half of RAM for compressed pages. Increasing the size of the device is important for small devices. For devices with 1GB of RAM, sizing ZRAM to 1 GiB allows successful installation with Anaconda. In general, it is expected that having more compressed swap will make the device more functional after installation too. This increase is the most important for devices with small amounts of memory (< 1 GiB), but will be beneficial to systems with slightly larger systems (1–8 GiB). Technically, this change is completely trivial, amounting to two lines of configuration. Nevertheless, there is some potential for problems with incompressible workloads. The experience with ZRAM so far makes the Change authors optimistic that no issues will be encountered, but users and other developers should be aware of the change. == Benefit to Fedora == Fedora works better on devices with low RAM. In particular, the installer can function. == Scope == * Proposal owners: change the defaults in `zram-generator-defaults` package to `zram-fraction=1.0`, `max-zram-size=8096`. * Other developers: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == Default configuration is changed. Systems with local configuration will not be affected. Systems which had zram-generator disabled will not be affected. == How To Test == Install the new version of the `zram-generator-defaults` package, execute `sudo systemctl daemon-reload && sudo systemctl restart swap-create@zram0`, use `zramctl` to check that the device has the expected size. After some use, check that pages are compressed at least with ration 2:1: $ zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lzo-rle 7.6G 4K 74B 12K 4 [SWAP] ^ ^^ |\\___ the ratio of those values should be more than 2:1 | `-- this should be approx the size of RAM (Note that the device is destroyed and recreated during restart. This means that all pages will be "swapped in", i.e. decompressed. On machines with low memory, rebooting might be a better option.) == User Experience == Not user visible. == Dependencies == None. == Contingency Plan == * Contingency mechanism: Revert default configuration to previous values. * Contingency deadline: Final freeze, any time really. * Blocks release? No * Blocks product? No == Documentation == None. == Release Notes == The default size of compressed zram devices (`/dev/zram0`) has been increased to 1.0 fraction of RAM, or 8 GiB, whichever is smaller. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@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/devel-announce@lists.fedoraproject.org
Fedora 34 Change: Scale ZRAM to Full Memory Size (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Scale_ZRAM_to_full_memory_size == Summary == Fedora 33 [[Changes/SwapOnZRAM|enabled zram by default]]. The size of the virtual swap devices was set so that the amount of memory used for compressed swap pages was limited to a quarter of physical memory in typical scenarios. That size is now increased to half of physical memory (`zram-fraction` becomes 1.0, `max-zram-size` becomes 8 GiB). This allows systems with small amounts to successfully launch the [https://anaconda-installer.readthedocs.io/en/latest/ Anaconda installer] and other programs. == Owner == * Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]] * Email: zbys...@in.waw.pl * Name: [[User:jwrdegoede|Hans de Goede]] * Email: hdego...@redhat.com == Detailed Description == When ZRAM was enabled by default in Fedora 33, the size of the device (before compression) was limited to fraction 0.5 of RAM or 4 GiB, whichever is less. The reason to limit the fraction to less than 1.0 is that with only incompressible data in memory, whole RAM would be filled by the "compressed" pages, leaving no RAM for normal use. But this concern seems to have been overblown, and there have been no reports of compressed swap taking up too much memory. In real use, we will have at least a few hundred MiB of code in memory, which compresses quite well, so some compression will occur even when working with incompressible data. In typical usage scenarios, we get effective compression of 2:1 or 3:1, which means that the compressed pages use at most between 1/4th and 1/6th of RAM. By increasing the fraction to 1.0, we expect to consign up to half of RAM for compressed pages. Increasing the size of the device is important for small devices. For devices with 1GB of RAM, sizing ZRAM to 1 GiB allows successful installation with Anaconda. In general, it is expected that having more compressed swap will make the device more functional after installation too. This increase is the most important for devices with small amounts of memory (< 1 GiB), but will be beneficial to systems with slightly larger systems (1–8 GiB). Technically, this change is completely trivial, amounting to two lines of configuration. Nevertheless, there is some potential for problems with incompressible workloads. The experience with ZRAM so far makes the Change authors optimistic that no issues will be encountered, but users and other developers should be aware of the change. == Benefit to Fedora == Fedora works better on devices with low RAM. In particular, the installer can function. == Scope == * Proposal owners: change the defaults in `zram-generator-defaults` package to `zram-fraction=1.0`, `max-zram-size=8096`. * Other developers: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == Default configuration is changed. Systems with local configuration will not be affected. Systems which had zram-generator disabled will not be affected. == How To Test == Install the new version of the `zram-generator-defaults` package, execute `sudo systemctl daemon-reload && sudo systemctl restart swap-create@zram0`, use `zramctl` to check that the device has the expected size. After some use, check that pages are compressed at least with ration 2:1: $ zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lzo-rle 7.6G 4K 74B 12K 4 [SWAP] ^ ^^ |\\___ the ratio of those values should be more than 2:1 | `-- this should be approx the size of RAM (Note that the device is destroyed and recreated during restart. This means that all pages will be "swapped in", i.e. decompressed. On machines with low memory, rebooting might be a better option.) == User Experience == Not user visible. == Dependencies == None. == Contingency Plan == * Contingency mechanism: Revert default configuration to previous values. * Contingency deadline: Final freeze, any time really. * Blocks release? No * Blocks product? No == Documentation == None. == Release Notes == The default size of compressed zram devices (`/dev/zram0`) has been increased to 1.0 fraction of RAM, or 8 GiB, whichever is smaller. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
