= 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.
== Scope ==
* Proposal owners: Package and include zram config and systemd units.
* Other developers: N/A (does not affect developers)
* Release engineering: #7607 [https://pagure.io/releng/issue/7607]
** List of deliverables: N/A
* Policies and guidelines: N/A (No updates to policies and guidelines required)
* Trademark approval: N/A (not needed for this Change)
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.
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?
Perhaps it's worth enabling on other arches as well?
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?
kevin
On Tue, Jul 10, 2018 at 10:50 PM, Kevin Fenzi kevin@scrye.com 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.
On Wed, Jul 11, 2018 at 8:50 AM, Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Jul 10, 2018 at 10:50 PM, Kevin Fenzi kevin@scrye.com 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.
On Tue, Jul 03, 2018 at 02:39:05PM +0200, 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.
== Scope ==
- Proposal owners:
Package and include zram config and systemd units.
Which "zram" config? There have been various attempts, e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1469726. Do you plan to reuse one of the existing projects, or create something from scratch?
Zbyszek
= 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.
== Scope ==
- Proposal owners:
Package and include zram config and systemd units.
Which "zram" config? There have been various attempts, e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1469726. Do you plan to reuse one of the existing projects, or create something from scratch?
I plan on creating one from new but using various information from these and other distros (I literally have dozens of tabs open of this ATM) and information from the upstream kernel maintainer. The various Fedora attempts all seem to be derived from one config [1]. The zram upstream has evolved since then.
On Wed, Jul 11, 2018 at 08:33:36AM +0100, Peter Robinson 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.
== Scope ==
- Proposal owners:
Package and include zram config and systemd units.
Which "zram" config? There have been various attempts, e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1469726. Do you plan to reuse one of the existing projects, or create something from scratch?
I plan on creating one from new but using various information from these and other distros (I literally have dozens of tabs open of this ATM) and information from the upstream kernel maintainer. The various Fedora attempts all seem to be derived from one config [1]. The zram upstream has evolved since then.
Thanks.
FWIW, I loaded the zram module on my laptop, and I see: - /dev/zram0 is created - /sys/block/zram0/max_comp_streams is 4, which matches the number of CPU threads I have (1 socket × 2 cores × 2 threads each).
So creating multiple devices like [1] seems pointless, and also adjusting max_comp_streams like anaconda does unnecessary. That simplifies things.
Zbyszek
On Wed, Jul 11, 2018 at 10:44 AM, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Wed, Jul 11, 2018 at 08:33:36AM +0100, Peter Robinson 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.
== Scope ==
- Proposal owners:
Package and include zram config and systemd units.
Which "zram" config? There have been various attempts, e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1469726. Do you plan to reuse one of the existing projects, or create something from scratch?
I plan on creating one from new but using various information from these and other distros (I literally have dozens of tabs open of this ATM) and information from the upstream kernel maintainer. The various Fedora attempts all seem to be derived from one config [1]. The zram upstream has evolved since then.
Thanks.
FWIW, I loaded the zram module on my laptop, and I see:
- /dev/zram0 is created
- /sys/block/zram0/max_comp_streams is 4, which matches the number of CPU threads I have (1 socket × 2 cores × 2 threads each).
So creating multiple devices like [1] seems pointless, and also adjusting max_comp_streams like anaconda does unnecessary. That simplifies things.
Correct, my intention is to create one device, this is the opinion of the upstream maintainer as well. It will keep things more simple, we have some ARM devices which have 10 cores and 1-2Gb of RAM, I don't see it makes sense to make 10 devices as it would likely affect the effectiveness of the swap if you have lots of small swap partitions.
Peter
The proposal suggests using zram device for swap, but doesn't say if there will be a secondary swap on disk.
Zram uses memory rather than a drive partition as backing, so it's useful for /tmp instead of tmpfs; and also when there isn't a swap partition on the local drive.
But if there is a backing device available, zswap uses compression to avoid swap until it can't and then pushes compressed data to swap device. So it moderates the abrupt drop off in performance when transitioning from memory to swap. Zram as swap will postpone that abrupt transition but in the case where it runs out of space, you're going to get that same abrupt fall off when swapping (or oom if no secondary swap is setup).
Anyway, I've been using zswap for a year and rarely hit swapping to the backing device.
Chris Murphy
On Wed, Jul 11, 2018 at 11:01 AM, Chris Murphy lists@colorremedies.com wrote:
The proposal suggests using zram device for swap, but doesn't say if there will be a secondary swap on disk.
Zram uses memory rather than a drive partition as backing, so it's useful for /tmp instead of tmpfs; and also when there isn't a swap partition on the local drive.
But if there is a backing device available, zswap uses compression to avoid swap until it can't and then pushes compressed data to swap device. So it moderates the abrupt drop off in performance when transitioning from memory to swap. Zram as swap will postpone that abrupt transition but in the case where it runs out of space, you're going to get that same abrupt fall off when swapping (or oom if no secondary swap is setup).
Anyway, I've been using zswap for a year and rarely hit swapping to the backing device.
OK so the questions are: - will there by a secondary swap device setup by the installer (primary being zram)? - why not just use zswap? - could the feature be a bit smarter, i.e. use zram when there's no backing device and use zswap when there is? - could the feature additionally use zram instead of tmpfs for /tmp? I guess the possible negative is this won't spill over into swap like tmpfs does.
Bit off topic but dracut uses /var/tmp to build up the initramfs during kernel updates and then copies it from /var/tmp to /boot while also compressing it. This seems rather suboptimal and definitely would benefit from /tmp in particular /tmp on a zram device. I'd already like to see this on may laptop and NUC server, but in particular for IoT the less writing to flash the better.
-- Chris Murphy
-
Chris Murphy -
Jan Kurik -
Kevin Fenzi -
Peter Robinson -
Zbigniew Jędrzejewski-Szmek