On Wed, Jul 11, 2018 at 8:50 AM, Peter Robinson <pbrobinson@xxxxxxxxx> wrote: > 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. I forgot to mention here I'm intending on using it on x86 for IoT and Hans has been investigating it on the Baytrail class of devices he's been working on and I've been collaborating with him on some of the detais. >> 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/RGVVWKUGP4FLBF4P4XXLQM4SLZHZHKJY/
