Closed StuartIanNaylor closed 1 week ago
@pelwell @popcornmix Thoughts?
Doesn't make sense to exclude a zram function that needs to be explicitly set to use.
The default is off unless as above echo /dev/sdxx > /sys/block/zramX/backing_dev
is set when creating the zram device.
It will be exactly the same apart from if someone wants to use a backing_dev then they can
The more oomf you give the pi then with limited memory zram does make much more sense.
Never got round to playing with the write_back cache as it was not enabled on rasbian.
The kernel doc is an atrocious read that zram_config.deb is actually misconstrued implementation, but that is another matter.
On arch enabled, it seemed to work, but my memory is foggy now.
Zram on the Pi is a really good addition, backing cache prob will be rarely used, but disabling whilst including zram wouldn't seem to make sense?
It will have no effect unless declared and enabled via echo /dev/sdxx > /sys/block/zramX/backing_dev
PS going back to zam the old deb script of zram_config has hung about from its first implementation and multi-streams and many things means that now its actually broken. Should not even be called zram_config as all it does is create a zram_swap badly for many reasons.
https://github.com/StuartIanNaylor/zram-swap-config
Above use hot_plug and is aware of other zram services and doesn't overwrite drives. Also because it is swap you can change page_cluster so its ram optimised not HD.
I did another as example of https://github.com/StuartIanNaylor/zram-config which uses a multiple of zram options and why zram_config is a narrow name.
Pi4 2GB really benefits from zram but also the overlayfs with zram upper and merge to lower emphemeral would be great for SD based Socs like the pi. Write once to SD on shutdown...
But just examples as for the Pi Zram is really beneficial especially now it has more oomf and prob could do with some better scripting than my hacks but maybe a base example. Writeback cache could be used but will have no detrimental effect as it needs to be declared on zram creation.
I was just stumbling about this while testing some various scenarios on the rpi z2w. Since this is open since 2019 and still not set (besides having CONFIG_ZRAM_MULTI_COMP=y would be nice too) - Is there any chance this might get changed? As already mentioned, it does not hurt and must be manually enabled, I would really appreciated to see this enabled in this module.
Adding ZRAM_WRITEBACK=y takes the uncompressed ARM64 binary module from 46kB to 59kB. ZRAM_MULTI_COMP=y adds an extra 6kB - which is not extravagant. Both of them seem to do nothing without being enabled explicitly via sysfs attributes.
Happy with this, @popcornmix?
I'm ok with this.
Thanks - merged.
Thank you! For enabling and the quick response!
Can
CONFIG_ZRAM_WRITEBACK=y
asecho /dev/sdxx > /sys/block/zramX/backing_dev
enables the write back also with further commands. Zram is enabled as a module but for some reason CONFIG_ZRAM_WRITEBACK=n ?