Hi, I know how to manually configure the zram, but what's the best way to do it?
I've seen the unit zram.service of anaconda-core, and it gets activated when booting with inst.zram=on, but it looks like very anaconda-centric.
Should something like [1] be packaged and included in the distro? or maybe we should spin off the anaconda zram.service and do it more generic.
I think this is a very interesting feature for memory constrained VMs and other devices.
Am 25.11.2014 um 21:03 schrieb Juan Orti:
Hi, I know how to manually configure the zram, but what's the best way to do it?
I've seen the unit zram.service of anaconda-core, and it gets activated when booting with inst.zram=on, but it looks like very anaconda-centric.
Should something like [1] be packaged and included in the distro? or maybe we should spin off the anaconda zram.service and do it more generic.
I think this is a very interesting feature for memory constrained VMs and other devices.
i am using the attached src.rpm for many months on Fedora (F19, F20)
El 2014-11-25 21:07, Reindl Harald escribió:
Am 25.11.2014 um 21:03 schrieb Juan Orti:
Hi, I know how to manually configure the zram, but what's the best way to do it?
I've seen the unit zram.service of anaconda-core, and it gets activated when booting with inst.zram=on, but it looks like very anaconda-centric.
Should something like [1] be packaged and included in the distro? or maybe we should spin off the anaconda zram.service and do it more generic.
I think this is a very interesting feature for memory constrained VMs and other devices.
i am using the attached src.rpm for many months on Fedora (F19, F20)
Thank you, works great. Shouldn't we package this for the distro?
Juan no need inst.zram=on on install on first boot modprobe zram ; systemctl start zram voila I use the default one in f21b no issues
Corey W Sheldon Freelance IT Consultant, Multi-Discipline Tutor 310.909.7672 www.facebook.com/1stclassmobileshine
On Wed, Nov 26, 2014 at 4:08 AM, Juan Orti juan.orti@miceliux.com wrote:
El 2014-11-25 21:07, Reindl Harald escribió:
Am 25.11.2014 um 21:03 schrieb Juan Orti:
Hi, I know how to manually configure the zram, but what's the best way to do it?
I've seen the unit zram.service of anaconda-core, and it gets activated when booting with inst.zram=on, but it looks like very anaconda-centric.
Should something like [1] be packaged and included in the distro? or maybe we should spin off the anaconda zram.service and do it more generic.
I think this is a very interesting feature for memory constrained VMs and other devices.
i am using the attached src.rpm for many months on Fedora (F19, F20)
Thank you, works great. Shouldn't we package this for the distro?
-- Juan Orti https://miceliux.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
2014-11-26 22:27 GMT+01:00 Corey Sheldon sheldon.corey@gmail.com:
Juan no need inst.zram=on on install on first boot modprobe zram ; systemctl start zram voila I use the default one in f21b no issues
Corey,
Why this service is part of anaconda-core ? and not with the base systemd or else ? On my installed workstation system, I can remove anaconda that is now undeeded but I would like to keep zram.service installed.
Thx for your answear.
Nicolas Chauvet
On Wed, 2014-11-26 at 23:46 +0100, Nicolas Chauvet wrote:
2014-11-26 22:27 GMT+01:00 Corey Sheldon sheldon.corey@gmail.com: Juan no need inst.zram=on on install on first boot modprobe zram ; systemctl start zram voila I use the default one in f21b no issues
Corey,
Why this service is part of anaconda-core ? and not with the base systemd or else ?
Because it is not a general-purpose service. It is a tailored version of service+scripts for use in the installation process.
On Wed, 2014-11-26 at 16:27 -0500, Corey Sheldon wrote:
Juan no need inst.zram=on on install on first boot modprobe zram ; systemctl start zram voila I use the default one in f21b no issues
For now. But the anaconda's zram.service is tailored to provide zram swap for the installation process. Future changes in it may make it unusable for general purpose usage on an installed system.
So packaging something general-purpose it definitely the right way to go. Reindl's scripts look good to me, I'd just suggest adding a configuration option for setting the maximum RAM for the zram swap being created. It doesn't make much sense to use it on systems with e.g. 32 GiB of RAM. That's by the way one of the tweaks the anaconda's version of the scripts+service has (hardcoded, though).
Am 27.11.2014 um 11:15 schrieb Vratislav Podzimek:
On Wed, 2014-11-26 at 16:27 -0500, Corey Sheldon wrote:
Juan no need inst.zram=on on install on first boot modprobe zram ; systemctl start zram voila I use the default one in f21b no issues
For now. But the anaconda's zram.service is tailored to provide zram swap for the installation process. Future changes in it may make it unusable for general purpose usage on an installed system.
So packaging something general-purpose it definitely the right way to go. Reindl's scripts look good to me, I'd just suggest adding a configuration option for setting the maximum RAM for the zram swap being created. It doesn't make much sense to use it on systems with e.g. 32 GiB of RAM. That's by the way one of the tweaks the anaconda's version of the scripts+service has (hardcoded, though)
"my script" supports a "percent of total RAM config" which i don't ship with the RPM because it's meant for internal usage (it's BTW a result of Google around after face the zram module with new kernels, took existing snippets from several sources, made them easier, fixed some bugs and introduced the systemd-unit)
[root@mail-gw:~]$ cat /etc/sysconfig/zram FACTOR=15
"It doesn't make much sense to use it on systems with e.g. 32 GiB of RAM" depends on the context - on a host mostly used for a lot of virtual machines it makes sense even with 64 GB or more - depends on the total count of guests and how much RAM they have assigend
instead have zram on all of the guests and to prevent danger of OOM events they may have all 2-3 GB RAM and while overcommit the host that way it can swap out most unsed guest memory without fall back to slow disk swapping
VMware ESXi does something similar for years to overcommit hosts http://pubs.vmware.com/vsphere-4-esx-vcenter/index.jsp?topic=/com.vmware.vsp...
El 2014-11-27 11:24, Reindl Harald escribió:
Am 27.11.2014 um 11:15 schrieb Vratislav Podzimek:
On Wed, 2014-11-26 at 16:27 -0500, Corey Sheldon wrote:
Juan no need inst.zram=on on install on first boot modprobe zram ; systemctl start zram voila I use the default one in f21b no issues
For now. But the anaconda's zram.service is tailored to provide zram swap for the installation process. Future changes in it may make it unusable for general purpose usage on an installed system.
So packaging something general-purpose it definitely the right way to go. Reindl's scripts look good to me, I'd just suggest adding a configuration option for setting the maximum RAM for the zram swap being created. It doesn't make much sense to use it on systems with e.g. 32 GiB of RAM. That's by the way one of the tweaks the anaconda's version of the scripts+service has (hardcoded, though)
"my script" supports a "percent of total RAM config" which i don't ship with the RPM because it's meant for internal usage (it's BTW a result of Google around after face the zram module with new kernels, took existing snippets from several sources, made them easier, fixed some bugs and introduced the systemd-unit)
[root@mail-gw:~]$ cat /etc/sysconfig/zram FACTOR=15 sion.html
Reindl, I'm of the opinion you should upload your scripts to some git repository and package them to be part of the distribution. I can co-maintain if you wish.
Am 27.11.2014 um 14:25 schrieb Juan Orti:
El 2014-11-27 11:24, Reindl Harald escribió:
Am 27.11.2014 um 11:15 schrieb Vratislav Podzimek:
On Wed, 2014-11-26 at 16:27 -0500, Corey Sheldon wrote:
Juan no need inst.zram=on on install on first boot modprobe zram ; systemctl start zram voila I use the default one in f21b no issues
For now. But the anaconda's zram.service is tailored to provide zram swap for the installation process. Future changes in it may make it unusable for general purpose usage on an installed system.
So packaging something general-purpose it definitely the right way to go. Reindl's scripts look good to me, I'd just suggest adding a configuration option for setting the maximum RAM for the zram swap being created. It doesn't make much sense to use it on systems with e.g. 32 GiB of RAM. That's by the way one of the tweaks the anaconda's version of the scripts+service has (hardcoded, though)
"my script" supports a "percent of total RAM config" which i don't ship with the RPM because it's meant for internal usage (it's BTW a result of Google around after face the zram module with new kernels, took existing snippets from several sources, made them easier, fixed some bugs and introduced the systemd-unit)
[root@mail-gw:~]$ cat /etc/sysconfig/zram FACTOR=15
Reindl, I'm of the opinion you should upload your scripts to some git repository and package them to be part of the distribution. I can co-maintain if you wish
feel free to package it!
that's why i attached it as i saw the topic i am not a active packager on the Fedora infrastrcuture
El 2014-11-27 14:48, Reindl Harald escribió:
Am 27.11.2014 um 14:25 schrieb Juan Orti:
Reindl, I'm of the opinion you should upload your scripts to some git repository and package them to be part of the distribution. I can co-maintain if you wish
feel free to package it!
that's why i attached it as i saw the topic i am not a active packager on the Fedora infrastrcuture
Ok, I've uploaded the scripts to GitHub and submitted a review request:
https://github.com/jorti/zram-swap https://bugzilla.redhat.com/show_bug.cgi?id=1168692
On Thu, Nov 27, 2014 at 04:42:36PM +0100, Juan Orti wrote:
El 2014-11-27 14:48, Reindl Harald escribió:
Am 27.11.2014 um 14:25 schrieb Juan Orti:
Reindl, I'm of the opinion you should upload your scripts to some git repository and package them to be part of the distribution. I can co-maintain if you wish
feel free to package it!
that's why i attached it as i saw the topic i am not a active packager on the Fedora infrastrcuture
Ok, I've uploaded the scripts to GitHub and submitted a review request:
https://github.com/jorti/zram-swap https://bugzilla.redhat.com/show_bug.cgi?id=1168692
I have a question about the code: why are multiple swap devices needed? /sys/block/zram0/max_comp_streams can be set to whatever number is wanted. While it might be useful to have additional zram devices for different purposes, I don't think more than one zram swap is useful. If you only have one device, then reloading the module is no longer necessary to change the parameters, since everything else seems to be configurable through sysfs.
Zbyszek
Am 28.11.2014 um 01:21 schrieb Zbigniew Jędrzejewski-Szmek:
On Thu, Nov 27, 2014 at 04:42:36PM +0100, Juan Orti wrote:
El 2014-11-27 14:48, Reindl Harald escribió:
Am 27.11.2014 um 14:25 schrieb Juan Orti:
Reindl, I'm of the opinion you should upload your scripts to some git repository and package them to be part of the distribution. I can co-maintain if you wish
feel free to package it!
that's why i attached it as i saw the topic i am not a active packager on the Fedora infrastrcuture
Ok, I've uploaded the scripts to GitHub and submitted a review request:
https://github.com/jorti/zram-swap https://bugzilla.redhat.com/show_bug.cgi?id=1168692
I have a question about the code: why are multiple swap devices needed? /sys/block/zram0/max_comp_streams can be set to whatever number is wanted. While it might be useful to have additional zram devices for different purposes, I don't think more than one zram swap is useful. If you only have one device, then reloading the module is no longer necessary to change the parameters, since everything else seems to be configurable through sysfs
i admit that i am not really sure, that part found by Google around and maybe that's a relict of zram before it made it to the upstream kernel
i guess /sys/block/zram0/max_comp_streams should be set to the number of CPU's and i ask my self why the default is 1 instead number of cores
On Fri, Nov 28, 2014 at 01:21:26AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Nov 27, 2014 at 04:42:36PM +0100, Juan Orti wrote:
El 2014-11-27 14:48, Reindl Harald escribió:
Am 27.11.2014 um 14:25 schrieb Juan Orti:
Reindl, I'm of the opinion you should upload your scripts to some git repository and package them to be part of the distribution. I can co-maintain if you wish
feel free to package it!
that's why i attached it as i saw the topic i am not a active packager on the Fedora infrastrcuture
Ok, I've uploaded the scripts to GitHub and submitted a review request:
https://github.com/jorti/zram-swap https://bugzilla.redhat.com/show_bug.cgi?id=1168692
I have a question about the code: why are multiple swap devices needed? /sys/block/zram0/max_comp_streams can be set to whatever number is wanted. While it might be useful to have additional zram devices for different purposes, I don't think more than one zram swap is useful. If you only have one device, then reloading the module is no longer necessary to change the parameters, since everything else seems to be configurable through sysfs.
And another question (sorry, I never used compressed swap before): why not zswap? It seems to be a better fit for the desktop/server environments that Fedora is used for. IIUC, zswap is better because it overflows automatically into the backing swap device.
Zbyszek
Am 28.11.2014 um 01:34 schrieb Zbigniew Jędrzejewski-Szmek:
On Fri, Nov 28, 2014 at 01:21:26AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Nov 27, 2014 at 04:42:36PM +0100, Juan Orti wrote:
El 2014-11-27 14:48, Reindl Harald escribió:
Am 27.11.2014 um 14:25 schrieb Juan Orti:
Reindl, I'm of the opinion you should upload your scripts to some git repository and package them to be part of the distribution. I can co-maintain if you wish
feel free to package it!
that's why i attached it as i saw the topic i am not a active packager on the Fedora infrastrcuture
Ok, I've uploaded the scripts to GitHub and submitted a review request:
https://github.com/jorti/zram-swap https://bugzilla.redhat.com/show_bug.cgi?id=1168692
I have a question about the code: why are multiple swap devices needed? /sys/block/zram0/max_comp_streams can be set to whatever number is wanted. While it might be useful to have additional zram devices for different purposes, I don't think more than one zram swap is useful. If you only have one device, then reloading the module is no longer necessary to change the parameters, since everything else seems to be configurable through sysfs.
And another question (sorry, I never used compressed swap before): why not zswap? It seems to be a better fit for the desktop/server environments that Fedora is used for. IIUC, zswap is better because it overflows automatically into the backing swap device
on machines with plenty RAM i prefer not have a swap partition or a swap file at all - especially on virtual machines it's a waste of (possible expensive SAN) disk storage
on virtual servers currently i prefer zram inside the guest to avoid OOM conditions in the guest while the memory compression of the hypervisor steps in too late and is more for overcommit the host
ok to the naming and multi zram devices questions:
1) one single large space is wasteful if you have your machine up for longer than a single (or series ) of heavy lifting operations --say you are rendering a video and then back to the usual grind stuff would you want all that extra space just wasted ? also say a follow up process is in need of more would you wanna be stuck on previous values? zram is dynamic in nature smaller more numerous /dev/zram$i allows for that and in a dynamic manner...
2) it the RAM its based off not swap and the "z" is known as dynamic
Corey W Sheldon Freelance IT Consultant, Multi-Discipline Tutor 310.909.7672 www.facebook.com/1stclassmobileshine
On Thu, Nov 27, 2014 at 7:39 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 28.11.2014 um 01:34 schrieb Zbigniew Jędrzejewski-Szmek:
On Fri, Nov 28, 2014 at 01:21:26AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Nov 27, 2014 at 04:42:36PM +0100, Juan Orti wrote:
El 2014-11-27 14:48, Reindl Harald escribió:
Am 27.11.2014 um 14:25 schrieb Juan Orti:
Reindl, I'm of the opinion you should upload your scripts to some git repository and package them to be part of the distribution. I can co-maintain if you wish
feel free to package it!
that's why i attached it as i saw the topic i am not a active packager on the Fedora infrastrcuture
Ok, I've uploaded the scripts to GitHub and submitted a review request:
https://github.com/jorti/zram-swap https://bugzilla.redhat.com/show_bug.cgi?id=1168692
I have a question about the code: why are multiple swap devices needed? /sys/block/zram0/max_comp_streams can be set to whatever number is wanted. While it might be useful to have additional zram devices for different purposes, I don't think more than one zram swap is useful. If you only have one device, then reloading the module is no longer necessary to change the parameters, since everything else seems to be configurable through sysfs.
And another question (sorry, I never used compressed swap before): why not zswap? It seems to be a better fit for the desktop/server environments that Fedora is used for. IIUC, zswap is better because it overflows automatically into the backing swap device
on machines with plenty RAM i prefer not have a swap partition or a swap file at all - especially on virtual machines it's a waste of (possible expensive SAN) disk storage
on virtual servers currently i prefer zram inside the guest to avoid OOM conditions in the guest while the memory compression of the hypervisor steps in too late and is more for overcommit the host
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
I recall that multiple zram devices are due to the way the device is handled - there's some need for multiple devices to allow multiple cores to operate concurrently against it.
zswap looks interesting. compcache/zram used to be able to setup a backing store that worked like zswap, but was poor performing. I think that if you wanted to eventually persist to disk, then zswap might be the way to go. If you don't want (or don't have) hard swap, then zram.
On Fri Nov 28 2014 at 13:41:42 Corey Sheldon sheldon.corey@gmail.com wrote:
ok to the naming and multi zram devices questions:
- one single large space is wasteful if you have your machine up for
longer than a single (or series ) of heavy lifting operations --say you are rendering a video and then back to the usual grind stuff would you want all that extra space just wasted ? also say a follow up process is in need of more would you wanna be stuck on previous values? zram is dynamic in nature smaller more numerous /dev/zram$i allows for that and in a dynamic manner...
- it the RAM its based off not swap and the "z" is known as dynamic
Corey W Sheldon Freelance IT Consultant, Multi-Discipline Tutor 310.909.7672 www.facebook.com/1stclassmobileshine
On Thu, Nov 27, 2014 at 7:39 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 28.11.2014 um 01:34 schrieb Zbigniew Jędrzejewski-Szmek:
On Fri, Nov 28, 2014 at 01:21:26AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Nov 27, 2014 at 04:42:36PM +0100, Juan Orti wrote:
El 2014-11-27 14:48, Reindl Harald escribió:
Am 27.11.2014 um 14:25 schrieb Juan Orti:
> Reindl, I'm of the opinion you should upload your scripts to some git > repository and package them to be part of the distribution. I can > co-maintain if you wish >
feel free to package it!
that's why i attached it as i saw the topic i am not a active packager on the Fedora infrastrcuture
Ok, I've uploaded the scripts to GitHub and submitted a review request:
https://github.com/jorti/zram-swap https://bugzilla.redhat.com/show_bug.cgi?id=1168692
I have a question about the code: why are multiple swap devices needed? /sys/block/zram0/max_comp_streams can be set to whatever number is wanted. While it might be useful to have additional zram devices for different purposes, I don't think more than one zram swap is useful. If you only have one device, then reloading the module is no longer necessary to change the parameters, since everything else seems to be configurable through sysfs.
And another question (sorry, I never used compressed swap before): why not zswap? It seems to be a better fit for the desktop/server environments that Fedora is used for. IIUC, zswap is better because it overflows automatically into the backing swap device
on machines with plenty RAM i prefer not have a swap partition or a swap file at all - especially on virtual machines it's a waste of (possible expensive SAN) disk storage
on virtual servers currently i prefer zram inside the guest to avoid OOM conditions in the guest while the memory compression of the hypervisor steps in too late and is more for overcommit the host
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Tue, Nov 25, 2014 at 09:03:20PM +0100, Juan Orti wrote:
Hi, I know how to manually configure the zram, but what's the best way to do it?
I've seen the unit zram.service of anaconda-core, and it gets activated when booting with inst.zram=on, but it looks like very anaconda-centric.
Should something like [1] be packaged and included in the distro? or maybe we should spin off the anaconda zram.service and do it more generic.
I think this is a very interesting feature for memory constrained VMs and other devices.
BTW, util-linux v2.26 (f22) is going to contain new command zramctl(8)
Karel
$ zramctl --help
Usage: lt-zramctl [options] <device> lt-zramctl -r <device> [...] lt-zramctl [options] -f | <device> -s <size>
Options: -a, --algorithm lzo|lz4 compression algorithm to use -b, --bytes print sizes in bytes rather than in human readable format -f, --find find a free device -n, --noheadings don't print headings -o, --output <list> columns to use for status output --raw use raw status output format -r, --reset reset all specified devices -s, --size <size> device size -t, --streams <number> number of compression streams
-h, --help display this help and exit -V, --version output version information and exit
Available columns (for --output): NAME zram device name DISKSIZE limit on the uncompressed amount of data DATA uncompressed size of stored data COMPR compressed size of stored data ALGORITHM the selected compression algorithm STREAMS number of concurrent compress operations ZERO-PAGES empty pages with no allocated memory TOTAL all memory including allocator fragmentation and metadata overhead MOUNTPOINT where the device is mounted
For more details see zramctl(8).
On Mon, 8 Dec 2014 11:36:47 +0100 Karel Zak kzak@redhat.com wrote:
On Tue, Nov 25, 2014 at 09:03:20PM +0100, Juan Orti wrote:
Hi, I know how to manually configure the zram, but what's the best way to do it?
I've seen the unit zram.service of anaconda-core, and it gets activated when booting with inst.zram=on, but it looks like very anaconda-centric.
Should something like [1] be packaged and included in the distro? or maybe we should spin off the anaconda zram.service and do it more generic.
I think this is a very interesting feature for memory constrained VMs and other devices.
BTW, util-linux v2.26 (f22) is going to contain new command zramctl(8)
Karel$ zramctl --help
Usage: lt-zramctl [options] <device> lt-zramctl -r <device> [...] lt-zramctl [options] -f | <device> -s <size>
Options: -a, --algorithm lzo|lz4 compression algorithm to use
can this work with HW accelerated compressors like the one in IBM Power CPUs? See eg. https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/W51a7...
Dan
-b, --bytes print sizes in bytes rather than in human readable format -f, --find find a free device -n, --noheadings don't print headings -o, --output <list> columns to use for status output --raw use raw status output format -r, --reset reset all specified devices -s, --size <size> device size -t, --streams <number> number of compression streams
-h, --help display this help and exit -V, --version output version information and exit
Available columns (for --output): NAME zram device name DISKSIZE limit on the uncompressed amount of data DATA uncompressed size of stored data COMPR compressed size of stored data ALGORITHM the selected compression algorithm STREAMS number of concurrent compress operations ZERO-PAGES empty pages with no allocated memory TOTAL all memory including allocator fragmentation and metadata overhead MOUNTPOINT where the device is mounted
For more details see zramctl(8).
-- Karel Zak kzak@redhat.com http://karelzak.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Mon, Dec 08, 2014 at 11:55:07AM +0100, Dan Horák wrote:
On Mon, 8 Dec 2014 11:36:47 +0100 Karel Zak kzak@redhat.com wrote:
BTW, util-linux v2.26 (f22) is going to contain new command zramctl(8)
Karel$ zramctl --help
Usage: lt-zramctl [options] <device> lt-zramctl -r <device> [...] lt-zramctl [options] -f | <device> -s <size>
Options: -a, --algorithm lzo|lz4 compression algorithm to use
can this work with HW accelerated compressors like the one in IBM Power CPUs? See eg. https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/W51a7...
Not sure, but it seems that zram currently supports only lzo and lz4 compression backends and boths are pure SW solutions. It does not use IMB nx-compression (kernel ./drivers/crypto/nx/nx-842.c).
Karel
Am 09.12.2014 um 11:24 schrieb Karel Zak:
On Mon, Dec 08, 2014 at 11:55:07AM +0100, Dan Horák wrote:
On Mon, 8 Dec 2014 11:36:47 +0100 Karel Zak kzak@redhat.com wrote:
BTW, util-linux v2.26 (f22) is going to contain new command zramctl(8)
$ zramctl --help
Usage: lt-zramctl [options] <device> lt-zramctl -r <device> [...] lt-zramctl [options] -f | <device> -s <size>
Options: -a, --algorithm lzo|lz4 compression algorithm to use
can this work with HW accelerated compressors like the one in IBM Power CPUs? See eg. https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/W51a7...
Not sure, but it seems that zram currently supports only lzo and lz4 compression backends and boths are pure SW solutions. It does not use IMB nx-compression (kernel ./drivers/crypto/nx/nx-842.c)
any chance to see util-linux v2.26 in F21?
On Tue, Dec 09, 2014 at 11:37:25AM +0100, Reindl Harald wrote:
any chance to see util-linux v2.26 in F21?
Ah sorry, I missed this your question...
Well, I'm going to push v2.26-rc1 to rawhide this week, and maybe (depends on feedback) later we can try to upgrade stable release in f21-testing. I usually don't do that and upgrade in rawhide only.
Karel
Am 13.01.2015 um 10:31 schrieb Karel Zak:
On Tue, Dec 09, 2014 at 11:37:25AM +0100, Reindl Harald wrote:
any chance to see util-linux v2.26 in F21?
Ah sorry, I missed this your question...
no problem
Well, I'm going to push v2.26-rc1 to rawhide this week, and maybe (depends on feedback) later we can try to upgrade stable release in f21-testing. I usually don't do that and upgrade in rawhide only
understandable, the zram features given there are no other regeressions may justify an exception
devel@lists.stg.fedoraproject.org
-
Corey Sheldon -
Dan Horák -
Darren Steven -
Juan Orti Alcaine -
Karel Zak -
Nicolas Chauvet -
Reindl Harald -
Vratislav Podzimek -
Zbigniew Jędrzejewski-Szmek