Patch applied. On Mon, Feb 03, 2014 at 10:33:37AM +0000, "Jóhann B. Guðmundsson" wrote: > On 02/03/2014 09:36 AM, Holger Schurig wrote: > >>with unit type ending in .zswap > >No, not another unit type. Instead better amend .swap unit types to > >also know about ZRAM. > > > >However, isn't this a bit early? Shouldn't move ZRAM first move out of > >staging? > > Ofcourse but when it does move out of staging we could have sorted > this implementation detail out which basically boils down to where > to set the partition sizes for the zram partitions ( > tmpfiles.d/zram-conf or /etc/zram.d/zram-conf ) > > Do we want a script that basically just set this size based on > available memory per core in the udev rule. > > factor=25 > num_cpus=$(grep -c processor /proc/cpuinfo) > memtotal=$(grep MemTotal /proc/meminfo | sed 's/[^0-9]\+//g') > mem_by_cpu=$(($memtotal/$num_cpus*$factor/100*1024)) > echo $mem_by_cpu
[Side note: I'm reading Documentation/blockdev/zram.txt... It says "1. modprobe zram num_devices=4". I can't help thinking that we went over this with /dev/loop-control and others... Since this is a new interface, why does it repeat the same pitfall of not having a control device?] Wouldn't it be simplest to have a parameter in /etc/fstab, like x.zram-disk-size=XXX, which swapon would write to /sys/block/.../disksize? This would make everything centralized and "synchronous" from the point of view of the administrator. Lennart Poettering wrote: > Quite frankly, I don't really see what the point is of involving a > fake block device for this... I am happy to generically support stuff > that makes sense, but this really and totally doesn't. It's a > completely broken API. You can use those devices also for other things... At some level it makes sense to provide this generic functionality instead of complicating other subsystems. Zbyszek _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
