On Wed, Jul 11, 2018 at 11:01 AM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > The proposal suggests using zram device for swap, but doesn't say if > there will be a secondary swap on disk. > > Zram uses memory rather than a drive partition as backing, so it's > useful for /tmp instead of tmpfs; and also when there isn't a swap > partition on the local drive. > > But if there is a backing device available, zswap uses compression to > avoid swap until it can't and then pushes compressed data to swap > device. So it moderates the abrupt drop off in performance when > transitioning from memory to swap. Zram as swap will postpone that > abrupt transition but in the case where it runs out of space, you're > going to get that same abrupt fall off when swapping (or oom if no > secondary swap is setup). > > Anyway, I've been using zswap for a year and rarely hit swapping to > the backing device. OK so the questions are: - will there by a secondary swap device setup by the installer (primary being zram)? - why not just use zswap? - could the feature be a bit smarter, i.e. use zram when there's no backing device and use zswap when there is? - could the feature additionally use zram instead of tmpfs for /tmp? I guess the possible negative is this won't spill over into swap like tmpfs does. Bit off topic but dracut uses /var/tmp to build up the initramfs during kernel updates and then copies it from /var/tmp to /boot while also compressing it. This seems rather suboptimal and definitely would benefit from /tmp in particular /tmp on a zram device. I'd already like to see this on may laptop and NUC server, but in particular for IoT the less writing to flash the better. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/YQYA2CL6X7GFMXEYBIBDGQUIXBPP4TPI/
