use zram-config by default

Bug #381059 reported by Craig on 2009-05-27
This bug affects 22 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
ubiquity (Ubuntu)
zram-config (Ubuntu)

Bug Description

There is already zram-config in Ubuntu, a package to enable compressed RAM swap:

Starting with kernel 3.8 zram (a rewrite of older compcache) is out of staging. Please enable it by default.

See also:

=== Original description ===

Including compcache by default can have a number of benefits for the average, and not so average, Ubuntu user.

For the average user, compcache will decrease disk swapping, which will increase perceived performance and decrease hits, which for laptop users will improve battery life. Since many users use laptops and netbooks these days, this is a big audience and would make many people happy. Desktop users will also benefit, as their disks will be less active and their electric bills may go down a tiny bit.

For the not-so-average user, such as those that run virtualization, they can run more VMs. With Ubuntu striving to be bigger in the server space, this could be a big deal. For me, I (unfortunately) run Windows in KVM, and it appears that enabling compcache improves my VM's performance.

Embedded devices and netbooks (such as those that run Ubuntu Netbook Remix) will benefit, as they have little RAM, and since compcache sort of increases RAM, it will make these devices more capable.

Since compcache is already in the Ubuntu kernel (see bug 200765), the only thing left is to either add an initramfs script or a udev script (IMHO, the udev approach is cleaner) as described here:



Anders Aagaard (aagaande) wrote :

It should atleast be considerably easier to add, maybe as an option in the install menu or something, that's enabled on systems with 1gb memory or less. Even on a system with 4gb memory compcache helps performance considerably (allowing io cache to function optimally without swapping all my programs).

Instead of modifying initramfs it might be an idea to add a meta package to automatically do that as well.

With 2.6.33 compcache is now shipped in the staging area, for Lucid+1 or whenever the .33+ switch is made this would at least remove the requirement to patch the kernel. Upstream also seems to have solved the scalability issue on multicore.

Jeremy Foshee (jeremyfoshee) wrote :

Hi Craig,

Please be sure to confirm this issue exists with the latest development release of Ubuntu. ISO CD images are available from . If the issue remains, please run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux 381059

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: needs-kernel-logs
tags: added: needs-upstream-testing
tags: added: kj-triage
Changed in linux (Ubuntu):
status: New → Incomplete
Craig (candrews-integralblue) wrote :

Lucid comes with the compcache module (ramzswap) but never uses it. As indicated in the description, if Ubuntu conditionally enabled compcache, low memory systems would benefit (such as embedded devices and netbooks). Since this behavior has not been changed, the bug is still valid.

Changed in linux (Ubuntu):
status: Incomplete → New
Martin Meyer (elreydetodo) wrote :

This is still an issue. I see that COMPCACHE is enabled in my lucid kernel:
$ grep COMPCACHE config-2.6.32-16-generic

The module name now is ramzswap. Probing it creates /dev/ramzswap0, which you can call swapon on. Using it is simple:
# modprobe ramzswap
# swapon /dev/ramzswap0 -p 100

Doing that simple stuff will cause an area of compressed ramdisk to be your highest priority swap disk. A nice init script with a configurable variable to specify the size to use is all that is needed. A little configuration dialog to put in the Administration would be nice. Would also be nice if the Ubuntu installer would detect small-ram conditions and offer to configure it automatically at install time.

Oibaf (oibaf) wrote :

Note: lucid appears to be using an obsolete version (0.5.3) of compcache:;a=blob;f=ubuntu/compcache/Changelog;h=a0ff085abd893ed314ea1604c5716d3789aba2b4;hb=ac5d9f160c0c615578f3fc563666b8efece04027

Latest is 0.6.2 and latest 0.5.x was 0.5.4. says:
"If you using kernel 2.6.28 or newer, you should use compcache-0.6.x instead."

Ambricka (petter-ambricka) wrote :

And the new version has a rzscontrol utility to control the ramzdisks.
As suggested by the author of ramzswap it would be better to make this a package which can easily be upgraded and include rzscontrol and man pages.

Rafal-maj-it (rafal-maj-it) wrote :

We should pack this utility. Debian begins to package it (not available yet, but probably soon)

I think this should be a very good idea. I have tested it on a old Pentium 3 with 512 MO of RAM and it works really better on heavy RAM usage.

I used 30 % of the local RAM to swap on with a high priority, and 512 Mo of HDD Good old Swap partition with a low swap priority and it seems to work transparently. Like if I have added an extra 512 Mo of RAM.

This PC have a hard drive so slow this pc is barely functional when he is swapping. Now it's ok, everything works smoothly !

This is a great piece of technology, I love this idea and what it opens.

This bug is missing log files that will aid in dianosing the problem. From a terminal window please run:

apport-collect 381059

and then change the status of the bug back to 'New'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Changed in linux (Ubuntu):
status: Incomplete → Expired
Oibaf (oibaf) on 2011-09-19
Changed in linux (Ubuntu):
status: Expired → Confirmed
Oibaf (oibaf) on 2012-12-02
description: updated
summary: - use compcache by default
+ use zram-config by default
description: updated
Oliver Grawert (ogra) wrote :

zram-config is in main since it exists, all thats needed is to seed it generally in the ship seed and to have some detection code in ubiquity that installs it by default in setups where it makes sense to have it (low ram)

Changed in zram-config (Ubuntu):
status: New → Invalid
Changed in ubiquity (Ubuntu):
status: New → Confirmed
importance: Undecided → Wishlist

I believe zram-config can be shipped unconditionally. It will decrease performance on a hypothetical machine with a slow CPU (or low memory bandwidth) and a really fast storage, but I couldn't find any such devices on the consumer market.

An Intel paper suggests that zramswap-like setups are beneficial even for ARM boards, which have slow CPUs and low memory bandwidth:

Oh, and as for Ubiquity, I've received reports that it enables zramswap on the installed system if no other swap is available to it. Perhaps that should be disabled.

Oibaf (oibaf) wrote :

Also note that kernel 3.8 will ship a faster lzo module, used by zram for compressing/decompressing RAM. See this commit and the others around it:;a=commitdiff;h=10f6781c8591fe5fe4c8c733131915e5ae057826

Take care of this if you want to do some benchmarks.

Anders Aagaard (aagaande) wrote :

I've got a system with 16gb ram, I still use zram. In the situations I do run low on memory (which happens, I do machine learning) zram will improve performance massivly. And I have yet to see a single benchmark where zram decreases system performance at all. In fact it'd be interesting to see numbers of a performance test using say 95% of the available memory with and without zram. Although I recon that would be a scenario that would be fairly rare.

I'd like to point out that zram is also more secure than swapping to a swap partition on the HDD; since the data never leaves memory, there's no need for cryptswap.

The Ubuntu kernels also have zswap since Saucy.
It may be a simpler option, needing only a change to the kernel command-line ( add "zswap.enabled=1" ).

Dimitri John Ledkov (xnox) wrote :

On my machine, which is a default desktop I have the following:
$ swapon -s
Filename Type Size Used Priority
/dev/sdc3 partition 33436668 0 -1
/dev/zram0 partition 2044092 0 5
/dev/zram1 partition 2044092 0 5
/dev/zram2 partition 2044092 0 5
/dev/zram3 partition 2044092 0 5
/dev/zram4 partition 2044092 0 5
/dev/zram5 partition 2044092 0 5
/dev/zram6 partition 2044092 0 5
/dev/zram7 partition 2044092 0 5

This is with Trusty. Does this mean it's used and enabled by default and therefore this bug can be closed?

Adolfo Jayme (fitojb) on 2014-02-24
no longer affects: linux (Ubuntu Raring)
no longer affects: ubiquity (Ubuntu Raring)
no longer affects: zram-config (Ubuntu Raring)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related blueprints