Re: [systemd-devel] swap on zram service unit, using Conflicts=umount
OK so I'm seeing with systemd.log_level debug at shutdown that there is a swapoff [ 406.997210] fmac.local systemd[1]: dev-zram0.swap: About to execute: /sbin/swapoff /dev/zram0 [ 406.997844] fmac.local systemd[1]: dev-zram0.swap: Forked /sbin/swapoff as 1966 [ 406.998308] fmac.local systemd[1]: dev-zram0.swap: Changed active -> deactivating [ 406.998332] fmac.local systemd[1]: Deactivating swap /dev/zram0... [ 406.999489] fmac.local systemd[1966]: dev-zram0.swap: Executing: /sbin/swapoff /dev/zram0 This happens after /home and /boot/efi are umounted, but before /boot and / are umounted. This is not unexpected, but I like the idea of no swapoff at reboot if that's possible. Any system under sufficient memory and swap pressure could very well have at least delayed shutdown if systemd shutdown/reboot actually waits for swapoff to exit successfully. Is there any interest in a systemd included swap on zram service to obviate the need for others basically reinventing this wheel? I kinda put it in the category of fstrim.service and the existing systemd cryptswap logic. I expect it wouldn't be enabled by default, but distros can enable or start it as their use cases dictate. Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] swap on zram service unit, using Conflicts=umount
On Tue, Jun 25, 2019 at 3:30 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Jun 25, 2019 at 10:55:27AM +0200, Lennart Poettering wrote: > > On Mo, 24.06.19 13:16, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) > > wrote: > > > > > > So for tmpfs mounts that don't turn off DefaultDependencies= we > > > > implicit add in an After=swap.target ordering dep. The thinking was > > > > that there's no point in swapping in all data of a tmpfs because we > > > > want to detach the swap device when we are going to flush it all out > > > > right after anyway. This made quite a difference to some folks. > > > > > > But we add Conflicts=umount.target, Before=umount.target, so we do > > > swapoff on all swap devices, which means that swap in the data after all. > > > Maybe that's an error, and we should remove this, at least for > > > normal swap partitions (not files)? > > > > We never know what kind of weird storage swap might be on, I'd > > probably leave that in, as it's really hard to figure out correctly > > when leaving swap on would be safe and when not. > > > > Or to say this differently: if people want to micro-optimize that, > > they by all means should, but in that case they should probably drop > > in their manually crafted .swap unit with DefaultDependencies=no and > > all the ordering in place they need, and nothing else. i.e. I believe > > this kind of optimization is nothing we need to cater for in the > > generic case when swap is configured with /etc/fstab or through GPT > > enumeration. > > Not swapping off would make a nice optimization. Maybe we should > invert this, and "drive" this from the other side: if we get a stop > job for the storage device, then do the swapoff. Then if there are > devices which don't need to stop, we wouldn't swapoff. This would cover > the common case of swap on partition. > > I haven't really thought about the details, but in principle this > should already work, if all the dependencies are declared correctly. I like the sound of this. The gotcha with current swap on zram units (there are a few floating out there including this one), is they conflate two different things: setup and teardown of the zram device, and swapon/swapoff. What's probably better and more maintainable would be a way to setup the zram device with a service unit, and then specify it in /etc/fstab as a swap device so that the usual systemd swapon/off behavior is used. Any opinion here? (Somewhat off topic: I wish zswap was not still experimental: by enabling zswap with an ordinary swap device, it creates a memory pool (which you can define a percentage of total RAM to use) that's compressed for swap before it hits the backing device. Basically, it's like a RAM cache for swap. It'll swap to memory first, and then overflow to a swap partition or file. It also lacks all the weird interfaces of zram.) https://wiki.archlinux.org/index.php/Improving_performance#Zram_or_zswap > > zswap is different: we know exactly that the swap data is located in > > RAM, not on complex storage, hence it's entirely safe to not > > disassemble it at all, iiuc. > > Agreed. It seems that any Conflicts= (including the one I proposed) are > unnecessary/harmful. OK I'll negate the commit that inserts it. -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] swap on zram service unit, using Conflicts=umount
On Tue, Jun 25, 2019 at 10:55:27AM +0200, Lennart Poettering wrote: > On Mo, 24.06.19 13:16, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > > So for tmpfs mounts that don't turn off DefaultDependencies= we > > > implicit add in an After=swap.target ordering dep. The thinking was > > > that there's no point in swapping in all data of a tmpfs because we > > > want to detach the swap device when we are going to flush it all out > > > right after anyway. This made quite a difference to some folks. > > > > But we add Conflicts=umount.target, Before=umount.target, so we do > > swapoff on all swap devices, which means that swap in the data after all. > > Maybe that's an error, and we should remove this, at least for > > normal swap partitions (not files)? > > We never know what kind of weird storage swap might be on, I'd > probably leave that in, as it's really hard to figure out correctly > when leaving swap on would be safe and when not. > > Or to say this differently: if people want to micro-optimize that, > they by all means should, but in that case they should probably drop > in their manually crafted .swap unit with DefaultDependencies=no and > all the ordering in place they need, and nothing else. i.e. I believe > this kind of optimization is nothing we need to cater for in the > generic case when swap is configured with /etc/fstab or through GPT > enumeration. Not swapping off would make a nice optimization. Maybe we should invert this, and "drive" this from the other side: if we get a stop job for the storage device, then do the swapoff. Then if there are devices which don't need to stop, we wouldn't swapoff. This would cover the common case of swap on partition. I haven't really thought about the details, but in principle this should already work, if all the dependencies are declared correctly. > zswap is different: we know exactly that the swap data is located in > RAM, not on complex storage, hence it's entirely safe to not > disassemble it at all, iiuc. Agreed. It seems that any Conflicts= (including the one I proposed) are unnecessary/harmful. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] swap on zram service unit, using Conflicts=umount
On Mo, 24.06.19 21:01, Chris Murphy (li...@colorremedies.com) wrote: > On Mon, Jun 24, 2019 at 6:11 AM Lennart Poettering > wrote: > > That said, I don't really grok zram, and not sure why there's any need > > to detach it at all. I mean, if at shutdown we lose compressed RAM > > or lose uncompressed RAM shouldn't really matter. Hence from my > > perspective there's no need for Conflicts= at all, but maybe I am > > missing something? > > Huh yeah, possibly if anything there could be low memory systems just > barely getting by with swap on zram, and even swapoff at reboot time > would cause it to get stuck. It might just be better to clobber it at > reboot time? > > I'd like to allow a user to 'systemctl stop zram' which does swapoff > and removes the zram device. But is there something that could go into > the unit file that says "don't wait for swapoff, if everything else is > ready for shutdown, go ahead and reboot now?" Not sure I follow? I mean, it should be enough to say in the .swap unit for zswap that there is no Conflicts towards a unit like shutdown.target, umount.target and so on. With that in place we'll leave the swap device up until the very end, but still allow users to manually stop it with "systemctl stop" if they like. It's just that systemd won't do that on its own during shutdown. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] swap on zram service unit, using Conflicts=umount
On Mo, 24.06.19 13:16, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > So for tmpfs mounts that don't turn off DefaultDependencies= we > > implicit add in an After=swap.target ordering dep. The thinking was > > that there's no point in swapping in all data of a tmpfs because we > > want to detach the swap device when we are going to flush it all out > > right after anyway. This made quite a difference to some folks. > > But we add Conflicts=umount.target, Before=umount.target, so we do > swapoff on all swap devices, which means that swap in the data after all. > Maybe that's an error, and we should remove this, at least for > normal swap partitions (not files)? We never know what kind of weird storage swap might be on, I'd probably leave that in, as it's really hard to figure out correctly when leaving swap on would be safe and when not. Or to say this differently: if people want to micro-optimize that, they by all means should, but in that case they should probably drop in their manually crafted .swap unit with DefaultDependencies=no and all the ordering in place they need, and nothing else. i.e. I believe this kind of optimization is nothing we need to cater for in the generic case when swap is configured with /etc/fstab or through GPT enumeration. zswap is different: we know exactly that the swap data is located in RAM, not on complex storage, hence it's entirely safe to not disassemble it at all, iiuc. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] swap on zram service unit, using Conflicts=umount
On Mon, Jun 24, 2019 at 6:11 AM Lennart Poettering wrote: > That said, I don't really grok zram, and not sure why there's any need > to detach it at all. I mean, if at shutdown we lose compressed RAM > or lose uncompressed RAM shouldn't really matter. Hence from my > perspective there's no need for Conflicts= at all, but maybe I am > missing something? Huh yeah, possibly if anything there could be low memory systems just barely getting by with swap on zram, and even swapoff at reboot time would cause it to get stuck. It might just be better to clobber it at reboot time? I'd like to allow a user to 'systemctl stop zram' which does swapoff and removes the zram device. But is there something that could go into the unit file that says "don't wait for swapoff, if everything else is ready for shutdown, go ahead and reboot now?" -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] swap on zram service unit, using Conflicts=umount
On Mon, Jun 24, 2019 at 02:11:03PM +0200, Lennart Poettering wrote: > On Sa, 22.06.19 10:42, Chris Murphy (li...@colorremedies.com) wrote: > > > Hi, > > > > I've got a commit to add 'Conflicts=umount.target' to this zram > > service based on a bug comment I cited in the comment. But I'm not > > certain I understand if it's a good idea or necessary. > > > > https://src.fedoraproject.org/fork/chrismurphy/rpms/zram/c/63900c455e8a53827aed697b9f602709b7897eb2?branch=devel > > > > I figure it's plausible at shutdown time that something is swapped > > out, and a umount before swapoff could hang (briefly or indefinitely I > > don't know), and therefore it's probably better to cause swapoff to > > happen before umount. > > So for tmpfs mounts that don't turn off DefaultDependencies= we > implicit add in an After=swap.target ordering dep. The thinking was > that there's no point in swapping in all data of a tmpfs because we > want to detach the swap device when we are going to flush it all out > right after anyway. This made quite a difference to some folks. But we add Conflicts=umount.target, Before=umount.target, so we do swapoff on all swap devices, which means that swap in the data after all. Maybe that's an error, and we should remove this, at least for normal swap partitions (not files)? > That said, I don't really grok zram, and not sure why there's any need > to detach it at all. I mean, if at shutdown we lose compressed RAM > or lose uncompressed RAM shouldn't really matter. Hence from my > perspective there's no need for Conflicts= at all, but maybe I am > missing something? > > Zbigniew, any particular reason why you added the Conflicts= line? It's been a while since I wrote that comment... Most likely I did it because that's the default combination that we use for units, and I didn't think that something different should be used for a swap service. Don't read too much into it. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] swap on zram service unit, using Conflicts=umount
On Sa, 22.06.19 10:42, Chris Murphy (li...@colorremedies.com) wrote: > Hi, > > I've got a commit to add 'Conflicts=umount.target' to this zram > service based on a bug comment I cited in the comment. But I'm not > certain I understand if it's a good idea or necessary. > > https://src.fedoraproject.org/fork/chrismurphy/rpms/zram/c/63900c455e8a53827aed697b9f602709b7897eb2?branch=devel > > I figure it's plausible at shutdown time that something is swapped > out, and a umount before swapoff could hang (briefly or indefinitely I > don't know), and therefore it's probably better to cause swapoff to > happen before umount. So for tmpfs mounts that don't turn off DefaultDependencies= we implicit add in an After=swap.target ordering dep. The thinking was that there's no point in swapping in all data of a tmpfs because we want to detach the swap device when we are going to flush it all out right after anyway. This made quite a difference to some folks. That said, I don't really grok zram, and not sure why there's any need to detach it at all. I mean, if at shutdown we lose compressed RAM or lose uncompressed RAM shouldn't really matter. Hence from my perspective there's no need for Conflicts= at all, but maybe I am missing something? Zbigniew, any particular reason why you added the Conflicts= line? Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] swap on zram service unit, using Conflicts=umount
Am 22.06.19 um 18:42 schrieb Chris Murphy: > I've got a commit to add 'Conflicts=umount.target' to this zram > service based on a bug comment I cited in the comment. But I'm not > certain I understand if it's a good idea or necessary. > > https://src.fedoraproject.org/fork/chrismurphy/rpms/zram/c/63900c455e8a53827aed697b9f602709b7897eb2?branch=devel > > I figure it's plausible at shutdown time that something is swapped > out, and a umount before swapoff could hang (briefly or indefinitely I > don't know), and therefore it's probably better to cause swapoff to > happen before umount. that's why i gave up with zram at all on servers from the moment on it really get used it makes troubles at shutdown with no real workaround, either swapoff fails at all because what should happen with the compressed paged out memory with no phyiscal backing or it takes ages which means your services are down for a long time while a oridanry reboot of a vserver without zram would take 4-10 seconds until everything is up again ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] swap on zram service unit, using Conflicts=umount
Hi, I've got a commit to add 'Conflicts=umount.target' to this zram service based on a bug comment I cited in the comment. But I'm not certain I understand if it's a good idea or necessary. https://src.fedoraproject.org/fork/chrismurphy/rpms/zram/c/63900c455e8a53827aed697b9f602709b7897eb2?branch=devel I figure it's plausible at shutdown time that something is swapped out, and a umount before swapoff could hang (briefly or indefinitely I don't know), and therefore it's probably better to cause swapoff to happen before umount. ? Thanks, -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
