Bug 572298 - RFE: Enable zswap
RFE: Enable zswap
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks: 582619
  Show dependency treegraph
 
Reported: 2010-03-10 14:18 EST by Nathaniel McCallum
Modified: 2014-12-02 09:00 EST (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 582619 (view as bug list)
Environment:
Last Closed: 2013-07-22 18:00:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Nathaniel McCallum 2010-03-10 14:18:22 EST
ramzswap is now in staging.  It has some very cool uses.  It would be trivial to add this to the kernel build config.
Comment 1 Bug Zapper 2010-07-30 07:01:32 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 2 Chuck Ebbert 2011-02-08 17:45:03 EST
A year later and it's now called zram. It's still in staging.
Comment 3 Chuck Ebbert 2011-02-24 13:15:32 EST
Note that because zram is still in staging it could be removed from the kernel at any time.
Comment 4 Piergiorgio Sartor 2012-02-01 16:54:03 EST
(In reply to comment #3)
> Note that because zram is still in staging it could be removed from the kernel
> at any time.

Oh, well, "nouveau" was long time in staging, nevertheless it was in Fedora too (almost not working).

On the other hand, I can understand you want to limit the kernel bug reports here, which are already quite a lot...

I would like to see "zram" (and "bcache") in the Fedora kernel too.

Please consider.

Thanks,

bye,

pg
Comment 5 Josh Boyer 2012-02-01 17:38:48 EST
(In reply to comment #4)
> I would like to see "zram" (and "bcache") in the Fedora kernel too.
> 
> Please consider.

We'll consider it when it's moved out of staging.
Comment 6 Josh Boyer 2013-05-16 16:36:54 EDT
Just noting zram is still in staging.  (So is zcache and zsmalloc.)  Re comment #4 we did enable CONFIG_BCACHE recently, as it moved into mainline.
Comment 7 Nathanel Titane 2013-06-23 15:33:58 EDT
+1 zram in mainline. We're approaching F19 release and still nothing about zram in fedora kernels... thanks for taking it in consideration.
Comment 8 Josh Boyer 2013-06-24 08:30:49 EDT
(In reply to Nathanel Titane from comment #7)
> +1 zram in mainline. We're approaching F19 release and still nothing about
> zram in fedora kernels... thanks for taking it in consideration.

Still in staging.  Still not enabling it.  It would be too late for F19 at this point anyway.
Comment 9 Nathanel Titane 2013-06-24 15:08:00 EDT
in a future update maybe?
Comment 10 Nathaniel McCallum 2013-07-01 13:44:05 EDT
A different approach has been taken upstream and is now called zswap. The good news is that zswap has been merged into -next and is slated for inclusion in 3.11.

http://lwn.net/Articles/552791/
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=08ca3dcd762434a1430345c4648863b6e65c49d9

Can we enable this for F20 when 3.11 is released? This would obviously be contingent on 3.11 actually containing zswap.
Comment 11 Piergiorgio Sartor 2013-07-01 14:07:34 EDT
Hi Nathaniel,

while I do not object to "zswap", I'm under the impression this is a completely different beast.

"zram" allows to create ramdisks, where the data is compressed, thus trading CPU load for space.

"zswap" seems it is compressing the pages swapped, thus trading, in case of swap, CPU load for speed (I/O to disk speed).

So, as said above, I'm not against "zswap", but this is not what I need.

Thanks anyway,

bye,

pg
Comment 12 Nathaniel McCallum 2013-07-01 15:47:45 EDT
Piergiorgio, You have misunderstood what zswap does. zswap compresses swap pages to memory and generally avoids writing them to disk at all. In essence it transparently compresses your main memory instead of using swap space. This was in fact the original intention of zram. That zram was implemented with compressed, memory-backed, block devices was merely an accidental detail.

zswap's implementation is better because it requires no manual setup and you can dynamically adjust the size of the cache pool.
Comment 13 Nathaniel McCallum 2013-07-01 15:50:03 EDT
If you want a compressed ramdisk filesystem, this is already doable without zram.
Comment 14 Piergiorgio Sartor 2013-07-01 16:07:33 EDT
Hi Nathaniel,

(In reply to Nathaniel McCallum from comment #12)
> Piergiorgio, You have misunderstood what zswap does. zswap compresses swap
> pages to memory and generally avoids writing them to disk at all. In essence
> it transparently compresses your main memory instead of using swap space.

OK, thanks, now it is more clear, but still it is different from "zram".

> This was in fact the original intention of zram. That zram was implemented
> with compressed, memory-backed, block devices was merely an accidental
> detail.

AFAIK, "zram" is an extension, or "generalization", of "zswap", supporting generic block device access.

> zswap's implementation is better because it requires no manual setup and you
> can dynamically adjust the size of the cache pool.

But with "zswap" I do not get a block device, which I can, for example, format with ext4 or, still as example, use as a RAID-1 member.

My target is to have a block device in RAM, with a certain flexibility, that, AFAIK, the usual ramdisk does not offer.

bye,

pg
Comment 15 Piergiorgio Sartor 2013-07-01 16:09:11 EDT
Hi again Nathaniel,

(In reply to Nathaniel McCallum from comment #13)
> If you want a compressed ramdisk filesystem, this is already doable without
> zram.

well, I do not need a compressed "filesystem" in RAM, but I'm anyway interested. How do I get that?

Thanks,

bye,

pg
Comment 16 Nathaniel McCallum 2013-07-01 16:25:42 EDT
zram and zswap are two different attempts to solve the problem of poor performance on memory constrained devices. This can be either because they have little memory (netbooks, phones, etc) or because they run software that uses lots of memory (vm servers, DB servers, etc). The zswap implementation is a better solution for this problem since it is faster and more dynamic.

If zram accidentally solved another problem for you, it was just that: an accident. There are many other tools for doing complex things: tmpfs, ramdisks, bcache, btrfs, etc. If you would like help solving a different problem, potentially with tools like these, there are lots of places to get this support. Bugzilla is not one of them. You could try the resources identified here: http://fedoraproject.org/en/get-help
Comment 17 Piergiorgio Sartor 2013-07-01 16:40:04 EDT
Hi Nathaniel,

(In reply to Nathaniel McCallum from comment #16)
> zram and zswap are two different attempts to solve the problem of poor
> performance on memory constrained devices. This can be either because they
> have little memory (netbooks, phones, etc) or because they run software that
> uses lots of memory (vm servers, DB servers, etc). The zswap implementation
> is a better solution for this problem since it is faster and more dynamic.

AFAIK, the story of "zram" started with "ramzswap" or similar approach, which was only valid for swap.
Then, someone extended it, creating "zram" as generic block device which *can* be used for swap, but not necessarily.
"zram" was designed as block device, with nothing to do with swap.
It just happened that a more  generic design was better.

> If zram accidentally solved another problem for you, it was just that: an

It is not "accidentally", it is the scope of "zram", to provide a compressed RAM block device.

Please have a look at:

https://lwn.net/Articles/388889/

Note the suggested use in /tmp or /var (which can be done with "tmpfs", of course, but this is not the point).

> accident. There are many other tools for doing complex things: tmpfs,
> ramdisks, bcache, btrfs, etc. If you would like help solving a different
> problem, potentially with tools like these, there are lots of places to get
> this support. Bugzilla is not one of them. You could try the resources
> identified here: http://fedoraproject.org/en/get-help

What have to do "tmpfs", "bcache" and the rest with "zram"?

The only possible comparison can be done with the standard "ramdisk", but this, last time I checked, was not flexible enough.
I'm not sure if something changed in the meantime, but "ramdisk", AFAIK, is not compressed and it is fully allocated at creation. Differently from "zram".

Finally, I do not understand your link to Fedora help.
The request here, as RFE, is to enable "zram", and only "zram", in Fedora kernel.
Not to enable a driver which supports partially the feature of "zram".

Please, check again what "zram" really is.

Thanks,

bye,

pg
Comment 18 Nathaniel McCallum 2013-07-01 16:54:29 EDT
pg, I am the original requestor. I know the history of both the feature and this bug.

ramzswap was started to ease memory contention on constrained devices. The implementation wasn't good enough.

zram was a rewrite of ramzswap to make it generic. Kernel developers don't like solving generic problems. This approach didn't go anywhere.

zswap solves ramzswap's problem in an elegant way. It got merged.

This bug was originally about ramzswap. The bug was renamed to zram since it looked like zram would solve ramzswap's problem. It didn't. zswap does. Hence, I'm renaming it again to zswap since zswap solves the original problem reported.

If you wish to have generic compressed block devices, please open a new bug since it is beyond the scope of this bug. But you should be aware that this feature is not likely to come out of staging soon, if ever.
Comment 19 Piergiorgio Sartor 2013-07-01 17:01:04 EDT
Hi Nathaniel,

fair enough, I joined this bug as "zram", because that is what I'm interested in.

I'll open a new one, if this switches to "zswap".

For the rest, I'm fully aware of the status of "zram", I'm doubtful too that we will ever go out of staging.

bye,

pg
Comment 20 Justin M. Forbes 2013-07-22 18:00:58 EDT
Zswap has been enabled in rawhide and will trickle down as 3.11 moves to stable releases
Comment 21 Yajo 2014-05-08 04:58:36 EDT
I'm sorry to ask in this old closed bug, but why is zswap not enabled in my F20 with kernel-3.13.9-200.fc20.x86_64?

`dmesg | grep zswap` shows nothing...

Thanks.
Comment 22 Bill McGonigle 2014-05-08 14:03:32 EDT
Yajo, zram is standard on 3.14 now:

$ ls -l /usr/lib/modules/3.14*/kernel/drivers/block/zram/zram.ko
-rw-r--r-- 1 root root 24479 Apr 28 11:05 /usr/lib/modules/3.14.2-200.fc20.x86_64/kernel/drivers/block/zram/zram.ko
Comment 23 Frank Ch. Eigler 2014-12-02 09:00:21 EST
Yajo, add "zswap.enabled=1" to the kernel boot options, in /etc/sysconfig/grub
or equivalent.

Note You need to log in before you can comment on or make changes to this bug.