Fedora Account System
Red Hat Associate
Red Hat Customer
ramzswap is now in staging. It has some very cool uses. It would be trivial to add this to the kernel build config.
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
A year later and it's now called zram. It's still in staging.
Note that because zram is still in staging it could be removed from the kernel at any time.
(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
(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.
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.
+1 zram in mainline. We're approaching F19 release and still nothing about zram in fedora kernels... thanks for taking it in consideration.
(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.
in a future update maybe?
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.
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
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.
If you want a compressed ramdisk filesystem, this is already doable without zram.
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
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
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
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
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.
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
Zswap has been enabled in rawhide and will trickle down as 3.11 moves to stable releases
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.
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
Yajo, add "zswap.enabled=1" to the kernel boot options, in /etc/sysconfig/grub or equivalent.