Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm using zram on my computer as a compressed RAM-backed swap. When the system needs to swap something out, swapping it to a zram-backed swap file is more or less equivalent to compressing that data in-memory to free up space. This makes swapping very fast most of the time, relative to disk-backed swap. Because of this, I wonder if there is some performance to be gained by encouraging the system to swap out unused stuff more aggressively, since it can do so without actually hitting the disk?

So has anyone messed around with, say, setting vm.swappiness to 100 while using zram? Would this be desirable?

sysctl -w vm.swappiness=100
share|improve this question

I would really not recommend to put the swappiness higher. A common mechanism in kernel is that it will put pages (chunk of memory) in the swap to free some memory for other running tasks.

First "problem" when the kernel wants n pages to be freed, m (with m < n, m is the number of compressed pages required to hold n) are newly created in RAM, I am not sure if that can disturb the kernel or not.

Then anyway, when you have pages in the swap, it is possible that you use the application later on with some of its pages in the swap. What the kernel do is bring back those pages into physical memory but does not remove them from swap (which with standard swap can be seen as caching, so when the application go back in the background, the kernel does not have to write back those pages into the slow swap). However with zram it is perhaps not a wise trick, because you then have in memory the m pages in zram + the n pages that are back in memory!

The kernel has normaly a "total memory" thatit can use to do its business. When you add zram, it is counting in the "swap" memory only, as it would be with any disk based swap, but it reduced the actual "total memory" and that is not expected/anticipated by the kernel. Sometimes you can have weird and not wanted behaviour because of this!

With zram, it would be good that the kernel does not swap too much to this area when it is under memory pressure. And you should always have a real hard disk swap partition bigger at least than your zram maximum size, so that the system won't get OOM whereas at the same time you would see plenty of free space as reported by free!

share|improve this answer

Pages needs to be swapped out (to disk) when memory is full. If you're using memory to create the place to swap out pages when memory is full, one would think it beats the purpose, except if the compression makes a difference (and then it would be natural to compress the memory directly instead of going through swap). Guess one would have to benchmark this, as computers are increasingly fast at compressing and decompressing compared to memory speed.

share|improve this answer
I've found zram-backed swap itself to be quite helpful when the system is running out of memory. It's saved me a few times from getting completely stuck in swapping hell and having to restart (I'm analyzing large data sets, so I need the memory, all 24 GB of it). I'm just wondering if the vm.swappiness value is tuned for disk-backed swap and if I should change it if I'll mostly be using zram-backed swap. – Ryan Thompson Mar 13 '12 at 4:35
"increasingly fast"? On the fly compression has been performing better than direct disk I/O for more than the past decade (its never going to be faster than memory access - that's not the point) – symcbean Mar 13 '12 at 10:47
symcbean, you forgot "compared to memory speed". Where is the disagreement? – Alexander Mar 13 '12 at 11:22
I think symcbean's point is that the goal of compressed memory backed pages (zram) is to replace swapping to physical medium. The reason it is not "natural to compress the memory directly" is because it would be fraught with complication for applications to have to determine which portions of its memory could be compressed and when; the VM subsystem is a much easier place to implement this. Workloads that benefit from zram have pages that aren't in the working set and can be easily compressed. – Daniel Papasian Jun 8 '13 at 11:44

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.