The Lubuntu team decided to enable the ZRAM module from the kernel in the next versions, starting from Saucy. The main reason is that the Ubiquity installer, in the Desktop Live version, is quite resource greedy and in some machines with low specs, explained shortly, the ZRAM module brings an additional amount of RAM.
I also see a very good reason to have ZRAM default enabled for the current use. Each time the system weakens under the load of several greedy applications started in the same span of time, the user will have the time to close a few tabs in Firefox or to close several programs he does not necessarily need at that moment, before the User Interface freezes completely!
I would like to add a modest contribution to this great idea. Here is what I would like to tell the Lubuntu team. The text is a bit long and will be pointed to from within a page of the Launchpad where a discussion about ZRAM started, as a blueprint.
I would like to drag attention to two points related to the configuration while using the ZRAM module:
=> The size of the ZRAM block device created, or block devices when there is more than one processor,
=> and the usual swappiness of the kernel, which often tends to start swapping when lots of RAM is still available.
History of ZRAM:
ZRAM is a kernel module which has been added with the kernel 2.6.38 in the staging directory where it is still located actually. It comes from the compache project, initiated and led by Nitin Gupta:
Personal experience with ZRAM:
My attention has been dragged to the Compcache project at it’s early stage.
We started using the ZRAM capability in our distributions at home in 2008 or 2009 with a script added in the rc.local file, such as this one:
open this link in your browser: http://pastebin.fr/29154 or this one: http://meets.free.fr/files/zram-config.txt
at that time we had to use the ramzswap module and the rzcontrol module from the compcache project in order to have the same effect as we get now by simply loading ZRAM from the kernel modules tree, using a script started as a service.
We had noticed that Nitin Gupta, the developer who created the Compcache project from where ZRAM is coming, had advised creating ZRAM block devices not larger than 25% than the available RAM for the reason that other processes in the system already use some memory for caching purpose.
In this page: http://code.google.com/p/compcache/wiki/CompilingAndUsingNew
we can read this comment from the author of the ZRAM module:
Comment by project member email@example.com, May 7, 2010
@Paczesiowa: ramzswap should not be given so much of memory as its just a (virtual) swap device — it can compress only anonymous (say, process stack, heap etc.) memory. There are also other kinds of caches in the system, say filesystem cache which also require lot of memory. So, to have a good balance among all the different caches, ramzswap should not be given nearly 100% of RAM.
Appropriate amount of ramzswap memory depends on kind of workload. For typical desktop workloads, I found 25% to work just fine (this is the default).
From our long experience, we have used the compcache device ZRAM since that time on several kinds of machines almost always with success on machines requiring more memory resources.
One of these machines where I had installed a minimal Debian with as many tweaks as possible was an AMD K7 with 650 Mhz and 512 Mb ram.
The distribution worked fine though it was fully snappy. For example while using Synaptic which might have been one of the most greedy programs installed then, I could notice in htop the memory was not the problem, in most cases what was slowing down the desktop was the cpu, where the resource was often raising up to 100%.
In my current machine, the use of ramzswap was helping me with the use of Virtualbox where I was often testing distributions and spins I was doing in one of the GNU/Linux communities.
The eldest machine on which I have used ZRAM was last year, a laptop HP Omnibook 6000, with a processor providing 780 Mhz (800 Mhz max) and 192 MB RAM!
It had two slots but would not accept/see more RAM (I had some of the same kind I could have used) and trying to update the BIOS with the hope it could fix it also came out impossible.
It had a Slitaz Linux distribution in it, but broken. I installed *antiX 12.5*, the first version based on Debian testing, made use of the zram-config from the antiX distribution (some of my friends helped fix their script which was still in a testing stage).
In that very old box with only 192 MB RAM:
I have been able to use Libreoffice, type a letter, save it, without feeling any sluggishness (also tweaked to start up faster with prelink);
- *with ZRAM configured to be loaded and using **25%** of the available RAM as a basis to fix it’s size;
- with a **control of the swappiness** handled in the sysctl.conf file
In the middle of last year, I started testing zram-config in Ubuntu, especially for a remix I am doing, with Openbox and without all the items provided by a full desktop: the goal is to go “even lighter” while still keeping the ease of use provided by flavors which come with a full desktop.
I soon noticed that the ZRAM module or modules created with zram-config was started (one ZRAM block device if there is a one core processor, two in my dual core machines) had a size which was 1/2 of the available RAM, instead of a 1/4 as I was used to have.
I also noticed that ZRAM was not loaded in the Live, sometimes and I was wondering why.
So I went seeking in the file system, under /etc and under /usr/share/initramfs-tools where the configuration files where located using “find” and “grep -R”, I found that the Ubuntu developers had thought not useful to have ZRAM used in machines having more than 512 MB RAM – and also that it was setup to create block devices as large as 1/2 of the available RAM!
This setup is found in the file /usr/share/initramfs-tools/hooks/compcache
Both of these setups seem wrong to me for the following reasons:
- 512 MB RAM is not enough to be used with some comfort, and I am not even speaking of the use of the Ubiquity installer;
- Using half of the RAM as a basis to setup the ZRAM device size seems not only wrong to me because it will trigger a higher use of the CPU for compression and decompression process, but also seems not necessary per my experience : with a normal use of a machine, the memory was never filled enough to need bigger block devices than the default ones as large as 25% of the RAM.
For the /usr/share/initramfs-tools/hooks/compcache file here is a patch I submit for use in Lubuntu:
(This file belongs to the initramfs-tools package).
I used to setup the default size of the ZRAM modules in the
/etc/initramfs-tools/initramfs.conf file, but it has been told to me on the qa-lubuntu mailing list that “compcache is deprecated”, so I checked in one of my installs and indeed the “COMPCACHE_SIZE=”25%” I had setup was ignored. Therefore I had to modify the setup directly in the zram-config.conf file under /etc/init in order to regain control over the size of the ZRAM block devices.
For the /etc/init/zram-config.conf file here is a patch I submit for use in Lubuntu: http://meets.free.fr/Downloads/BentoVillageProject/Configurations/System/Zram/etc/init/zram.config.conf.patch
There is also a bug which needs to be known about the zram-config package: https://bugs.launchpad.net/ubuntu/+source/zram-config/+bug/1036339 Title: “zram-config runs even after uninstalled, needs purge”
I can confirm this bug report, having observed it once. (But I don’t quite remember the details now, I think I struggled to fix it).
For information adding the use of ZRAM to a Debian spinoff this year: Install ZRAM in Debian.
It came out that the work of several contributors allowed to get a setup working fine in Debian, with the older init system. I host the product of this work here:
Swappiness: the configuration file /etc/sysctl.d/50-local.conf fixed with the following:
# Uncomment the next line if we are running a laptop
# vm.laptop_mode = 1
is what I have used the last months as well as several people who tested and are using a remix done with this setup, on different machines.
You could argue the swappiness could be another topic in this blueprint, and perhaps it would be? Right now I am unsure because both could be linked. I intend to test further, by installing Lubuntu Saucy final testing version (Desktop version) with the default setup to a machine with low specs.
The results about the above said tests will be published in a next post. Stay tuned.