lubuntu-qa team mailing list archive

[JM <meets@xxxxxx>]

On Sat, 26 Oct 2013 20:37:04 +0200
Leszek Lesner <leszek.lesner@xxxxxx> wrote:

> As some of you know there were some discussions on this mailinglist
> regarding zram and vm.swappiness.
> In this mail I want to write down all I know and learned about zram,
> vm.swappiness and its cooperation.
> This is intend as a help and a starting point for discussions for the
> next release of Lubuntu which will be an LTS.
> 
> I have to thank Mélodie for the discussions about vm.swappiness which
> made me dig deeper and deeper into it.
> And I have to say I was wrong at least partly :P
> 
> So before talking about ZRAM a small comprehensive introduction what it is.
> ZRAM is a compressed virtual swap device that lives in RAM. With this it
> is possible to use and store more memory
> that is physically available. It is used by Lubuntu in 13.10 by default.
> 
> What is vm.swappiness ? That is a far more complicated thing to explain.
> Simply speaking it controls the balance between swapping out runtime
> memory,
> as opposed to dropping pages from the system page cache. It can have a
> value from 0 to 100.
> A lower value means that it will try not to swap out page cache but keep
> it in memory.
> A high value means try to more aggressively swap out unused page memory.
> 
> A discussion was started if Lubuntu should lower down the vm.swappiness
> value or even set it down to 0
> to improve system performance and responsiveness.
> In my initial thought that I could give a universal answer on this topic
> but I was wrong.
> There a several scenarios we need to take a look at to see that there is
> not an universal answer on this.
> 
> == The classical situation (before 13.10): ==
> * RAM + SWAP (on HDD)
> 
> The RAM is backed up by a SWAP partition or SWAP file which is stored on
> a harddrive or ssd.
> As we all know disk i/o is a lot slower than RAM. On older machines and
> slower disks this could lead to noticable
> lags while swapping. But also on normal machines it is noticable. So for
> this scenario it would be nice to tell the
> kernel to avoid swapping as much as possible to avoid this bottleneck.
> A low vm.swappiness or even 0 is a good setting here as the kernel keeps
> filling the ram until it is almost full and then
> starts swapping out which could make the system laggy for a few seconds
> and while writing data to swap. So there is an unavoidable
> bottleneck here but there is also the possibility that with enough ram
> and a low memory footprint of the apps and desktop that
> the user will not reach the point of swapping.
> 
> == The new modern situation (with 13.10¹): ==
> * RAM + ZRAM
> 
> The RAM is backed up by a SWAP partition which is stored on a virtual
> compressed ram device. Under Lubuntu
> 13.10 this device can use half of the physically available memory.
> Writing and reading to and from RAM is a hell lot faster than to disk
> (even to an SSD). This means there is no bootlneck
> when the system swaps out to ZRAM with its default swappiness settings.
> Setting the swappiness lower here would make a change but
> a very minor only (noticable only via benchmarks). And lowering it here
> might lead to a faster reaching of the second
> bottleneck. So avoiding swapping and letting the RAM be filled and
> swapping late especially when RAM is very full will slow down the
> system and produces noticable lags. Those lags might be even harder in
> this case because the pages need to be compressed into RAM and
> when new pages need to be placed into RAM at the same time this might
> lead to a long cpu 100% compressing decompressing moving loop.
> Letting the swappiness at default (60) or even set it higher to 100
> would help avoid this bottleneck as swapping early would avoid
> RAM running full too fast.
> Whats the downside ?
> The CPU has to compress and decompress more often (don't worry even a
> Pentium 3 is very fast at it) and this causes more wake up times
> for the CPU. (perhaps a downside for those who want to save every little
> watt of there notebook battery)
> 
> == The combination of both situations : ==
> * RAM + ZRAM + SWAP (on HDD)
> 
> The RAM is backed up by ZRAM and a SWAP partition/file. This is an usual
> setting if you have very low RAM (like 256/512MB or 1 GB).
> By default ZRAM is as Swap device has a higher priority than the swap
> partition/file on hd. The swapping mechanism now works very clevely
> and swaps out first and by default early to zram first until its full.
> Then it will start swapping to hdd.
> This will lead us to our bottleneck nr.1 again but in contrast to the
> classical situation (scenario 1) it will get there a lot later :)
> So is there a possibility to avoid this bottleneck by changing the
> swappiness ? No not really.
> Swappiness low would lead too faster filling in memory which will lead
> (especially on low memory systems) lead to bootlneck 2 which tends
> to make the system a lot laggier than bottleneck 1.
> Setting swappiness higher here would be also only work until ZRAM is
> filled and than would lead to bottleneck 1 again.
> So overall I would recommend the default swappiness value here which
> tends to keep the system in a good balance between bottleneck 1 and 2.
> 
> So all in all when you see this scenarios I have to say that the default
> value of swappiness 60 makes the most sense as the default value
> of lubuntu. Changing it for the next release is something I would not
> recommend.
> 
> Seeing this one could ask wouldn't it be good to directly compress any
> data written to RAM ?
> And yes this is a possibility in the future with zcache (which is
> basically a backend for cleancache which is a whole framework around it).
> Zcache compresses every page cache written to RAM which will lead to
> more available free memory.
> And yes it is even possible to combine ZCache (Page Cache[Disk Cache and
> so on]) and ZRAM (Application memory) which
> could lead to even more available free RAM and might even make it
> possible to completely get rid of SWAP partitions/files on hdd.
> In the making is also frontswap which is basically speaking zram but
> without the necessity to give it a fixed size. So it can dynamically
> grow.
> 
> So the future looks very promising when it comes to low ram management
> and we are on a good way.

Hi,

This is a great presentation. I must say I have not yet tried the distro on the eldest
machine of the house here, but I will as soon as possible and I will bring a detailed
feedback.

I still disagree with you on two points, is the level of swappiness, because my
experience shows that even when setup to 0 it will still start to swap to disk while a
little amount a RAM is still available, and the feeling for slowness starting when the
system starts swapping is quite present. (On a very old machine with very little RAM and
small CPU, poor Graphics, and on a very recent with lots of RAM and a good strong CPU).

Of course swapping to the compressed zram device is faster than swapping to disk! This
is the very interesting point about using zram. (I suppose my swap partitions are
really used only when putting the system to sleep/hibernation - but that concerns
machines with enough resource, such as dual cores with at least 2 GB Ram where the most
greedy application I use is probably Virtualbox with a light system running in it).

One point I didn't read about in your explanation is about the size of the ZRam swap
block device: the author or the program himself did suggest that 25% for a machine used
as a desktop would be the best setup, according to his tests, benchmarks, and given the
fact that other processes in the system already use some ram for their caching needs.

I am not sure I said it all the right way in the English language, however I hope there
isn't any big mistake. I will just invite you to also visit the brainstorming about ZRam
started on the launchpad, and where phillw invited me to post and where I develop the
suggests and point to another longer presentation of the experience I had so far with
ZRam:
https://blueprints.launchpad.net/lubuntu-brainstorming/+spec/zram-config

In the "long story" I point to at the end of my message on the above page, you will find
more about experience and links to the precise part of the compcache page where I get the
information related to Nitin Gupta, the author of Zram and the Compcache project. 

Regards,
Mélodie