On Tue, Jul 10, 2018 at 10:50 PM, Kevin Fenzi <kevin@xxxxxxxxx> wrote: > On 07/03/2018 05:39 AM, Jan Kurik wrote: >> = Proposed System Wide Change: ZRAM support for ARM images = >> https://fedoraproject.org/wiki/Changes/ZRAMforARMimages >> >> >> Owner(s): >> * Peter Robinson <pbrobinson at fedoraproject dot org> >> >> >> Enable ZRAM for swap on ARMv7 and aarch64 pre generated images to >> improve performance and reliability on ARM Single Board Computers such >> a the Raspberry Pi. >> >> >> == Detailed description == >> Current Fedora release artifacts for ARM platforms enable a small >> amount of swap by default. While this has generally works OK in the >> past it can cause a number of issues primarily wearing out SD cards >> due to excess use of wear leveling. ZRAM can mitigate this and provide >> more memory for ARM SBCs by compressing part of memory and using it as >> a swap space. This provides better performance and improved >> reliability across this class of device which overall provides a >> better end user experience. > > So, it looks like anaconda has zram support and enables it if there's > 2GB memory or less or you pass 'inst.zram=1' on the boot line. It does. > How does this interact with that? Could we perhaps get both of them to > use the same setup so we don't have multiple places we enable this? It doesn't, my understanding from a quick look is that anaconda doesn't do anything persistent but rather loads the module and pokes at the sys interface. I admit though I've not yet looked closely at their implementation, although it is on my todo list. Also on my todo list is possibly integrating with anaconda that it installs/enables it when certain criteria are met similar to what it does with other things like disk utilities if a particular FS is used although this would likely be a future release once we better know how well it works, side effects etc. > Perhaps it's worth enabling on other arches as well? Quite probably. There will be nothing arch specific about the implementation. My intention here is to enable it on the pre-canned images we produce for ARM. It's probably something worth looking at for live images too but it's not something I have much interest in, although I am very happy to assist those that might be once we've got some data on how it's looking on the ARM images. > Finally I wonder if the 2GB limit is still right? > Should we increase that? I have heard of lot of people say recent > releases need more memory, this might help that out? I believe it would likely be useful on higher memory devices, enabling it on the ARM pre canned images means we're looking at devices in the 512Mb to 8Gb range with most <=2Gb. In this range of devices it also has the advantage that the swap won't pound the usually mSD/emmc storage with the impact on wear leveling etc, this later is as much the reason for doing it as the better performance. I think there's a bunch of things we'll tweak as we go and I don't expect to be placing a stick in the mud and calling this done. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/DVVUGSE3ALUH4SLE5R2IPOR4I3Q2P3DK/
