action #89734
closed[SLE-17630][PM-2253] Low mem devices like ARM-based, IoT, VMs, etc. can be installed (or installed faster) when using swap on zram
0%
Description
Feature aims low memory installations where zram is of a great help.
Feature is available in TW and SLES.
What to cover:
- Low memory installations on different architectures
- Test zram, zram.swap and zram.root options
- Recognize how many modules can be enabled with qt installation with Y2DEUG=1 (each module increases memory consumption)
- Check defaults (zram disabled by default)
- Evaluate how much it speeds up installation to consider usage of zram=1 in some slow installations
- Follow-up ticket for automation
- Provide feedback to the YaST team
Useful links¶
- https://jira.suse.com/browse/SLE-17630
- https://jira.suse.com/browse/PM-2253
- https://jira.suse.com/browse/SLE-17636 (see comment from Lukas with bug references)
- https://github.com/openSUSE/linuxrc/pull/246
- https://en.opensuse.org/SDB:Linuxrc
- https://w3.nue.suse.com/~lpechacek/fate-archive/318957.html
Trello card content:
https://jira.suse.com/browse/PM-2253
This is the common scenario of every GA and SP: We keep adding new features and packages, QA tests some of them and then with RC phase, Beta customers start testing. And they find problems. Some of them are usually about not enough memory.
This idea is about using some special Kernel module that compresses the main memory, zram. Fedora already uses that, Raspbian / Ubuntu too. It not only speeds up installation on small-RAM systems, it sometimes makes it even "possible" to install on them.
It's an internal change, I believe that if we test it well, we can introduce it even in SLE 15 SP3.
See more some notes/questions/links in https://trello.com/c/eLEqACEs/3736-zram-zswap-in-inst-sys
Review¶
- https://github.com/openSUSE/linuxrc/pull/246
- https://github.com/openSUSE/installation-images/pull/462
- https://github.com/openSUSE/linuxrc/pull/249
- doc: https://en.opensuse.org/SDB:Linuxrc#p_zram
Testing showed overall positive effects (see linuxrc PR) and no visible drawbacks.
I've submitted this also to SP3 and disabled it per default as we are too late in the release cycle. Can be enabled with a simple option if needed.¶
Updated by JERiveraMoya about 3 years ago
- Status changed from Workable to In Progress
Updated by JERiveraMoya about 3 years ago
SLE (x86_64 RAM 512 M):¶
- install medium: SLE-15-SP3-Online-x86_64-Build.162.7-Media1.iso (RC1Candidate)
- RAM 512 M | 1 CPU | Hard disk 20 G
- linuxrc version: 7.0.30
- linuxrc params: regurl=http://all-162.7.proxy.scc.suse.de YDEBUG=1
- Registering 7 modules: Basesystem, Server, Legacy, Web and Scripting, Containers, Desktop and Development
- System Role: SLES with GNOME
**Without zram:**
1. no params
Stuck in 'Read device configuration'
**Only zram.swap**
2. zram.swap=512M
System installed and boots OK
3. zram.swap=1G
Comparing with 512M, speeds up in the registration and installation of package aprox. 20 second (not very significative)
4. zram.swap=2G
Comparing with 1G is lightly slower.
**Only zram.root**
5. zram.root=512M
Very SLOW, unusable when registering the first module.
6. zram.root=1G
SLOW, unusable when registering the first module.
7. zram.root=2G
Very SLOW, unusable even before selecting modules
**Combination of zram.root and zram.swap**
8. zram.root=512M zram.swap=512M
9. zram.root=1G zram.swap=512M)
10. zram.root=512 zram.swap=1G)
11. zram= 1 (zram.root=1G zram.swap=1G)
In the 4 cases system installed and boots OK
In registration/installation of package phases there were no significative difference of time.
512M/512M combination was the first to finish installation by 15 seconds (other factors could affect the time but was not the last one)
so 1G/1G seems to me a good default to give some more margin.
12. AutoYaST with no params (using some more cumbersome [profile](https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/data/autoyast_sle15 /autoyast_multi_btrfs.xml) and 4 disks.
Stuck in 'Initializing' dialog.
13. AutoYaST zram=1
Installations succeeded and system booted properly.
TW (x86_64 RAM 512 M):¶
- install medium: openSUSE-Tumbleweed-DVD-x86_64-Snapshot20210316-Media.iso
- RAM 512M | 1 CPU | Hard disk 20 G
- linuxrc version: 7.0.30
- linuxrc YDEBUG=1
**Without zram:**
1. no params
linuxrc error
**Only zram.swap**
2. zram.swap=512M
3. zram.swap=1G
4. zram.swap=2G
linuxrc error in all of them
**Only zram.root**
5. zram.root=512M
6. zram.root=1G
7. zram.root=2G
linuxrc error in all of them
**Combination of zram.root and zram.swap**
8. zram= 1 (zram.root=1G zram.swap=1G)
9. zram.root=2G zram.swap=2G
linuxrc error in all of them
TW (x86_64 RAM 1024 M):¶
- install medium: openSUSE-Tumbleweed-DVD-x86_64-Snapshot20210316-Media.iso
- RAM 1024M | 1 CPU | Hard disk 20 G
- linuxrc version: 7.0.30
- linuxrc YDEBUG=1
- System Role: Desktop with KDE Plasma
**Without zram:**
1. no params
Stuck in 'Add-On Products'
**Only zram.swap**
2. zram.swap=512M
3. zram.swap=1G
4. zram.swap=2G
No difference among them. All work.
**Only zram.root**
5. zram.root=512M
6. zram.root=1G
7. zram.root=2G
All got stuck after partitioning.
**Combination of zram.root and zram.swap**
8. zram.root=512M zram.swap=512M
9. zram.root=1G zram.swap=512M)
10. zram.root=512 zram.swap=1G)
11. zram= 1 (zram.root=1G zram.swap=1G)
All worked fine in similar way, as the zram.swap seems to be the most important factor.
Updated by JERiveraMoya about 3 years ago
Comparing our current openQA configuration with and without zram=1:
select_modules_and_patterns_without_zram@aarch64 vs select_modules_and_patterns_with_zram@aarch64
select_modules_and_patterns_without_zram@64bits vs select_modules_and_patterns_with_zram@64bits
select_modules_and_patterns_without_zram@ppc64le vs select_modules_and_patterns_with_zram@ppc64le
select_modules_and_patterns_without_zram@s390x-kvm-sle12 vs select_modules_and_patterns_with_zram@s390x-kvm-sle12
Summary of improvements on time executions:
1 min in scc_registration for aarch64 and 64bits
4 mins in select_patterns and await_install in 64bits.
Updated by JERiveraMoya about 3 years ago
- Status changed from In Progress to Feedback
Updated by JERiveraMoya about 3 years ago
- Status changed from Feedback to Closed