Re: [PATCH v2] mm: Enable suspend-only swap spaces

[Evan Green <evgreen@chromium.org>]

On Fri, Jul 9, 2021 at 3:20 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Fri,  9 Jul 2021 10:50:48 -0700 Evan Green <evgreen@chromium.org> wrote:
>
> > Currently it's not possible to enable hibernation without also enabling
> > generic swap for a given swap area. These two use cases are not the
> > same. For example there may be users who want to enable hibernation,
> > but whose drives don't have the write endurance for generic swap
> > activities.
> >
> > Add a new SWAP_FLAG_NOSWAP that adds a swap region but refuses to allow
> > generic swapping to it. This region can still be wired up for use in
> > suspend-to-disk activities, but will never have regular pages swapped to
> > it.
> >
> > Swap regions with SWAP_FLAG_NOSWAP set will not appear in /proc/meminfo
> > under SwapTotal and SwapFree, since they are not usable as general swap.
> >
>
> This patch doesn't appear to set SWAP_FLAG_NOSWAP anywhere.  Perhaps
> there's another patch somewhere which changes the hibernation code?  If
> so, can we please have both patches in a series?

There's no other patch, in the kernel at least. SWAP_FLAG_* is exposed
to usermode, which would set it when calling swapon(2). Once this
patch is accepted, I'll have to add the option into util-linux [1], so
that I can use it in my init scripts.

Said a different way, this patch isn't about altering how hibernate
behaves, but about giving usermode the freedom to set up hibernate and
swap independently.

[1] https://github.com/karelzak/util-linux/blob/b4533177aeac287e0b0563cd1b9ee61bce29ee88/sys-utils/swapon.c#L710

>
> Once we have a description of how this thing gets set, please let's
> discuss what happens if someone tries to enable generic swap onto that
> device after hibernation has set SWAP_FLAG_NOSWAP (I'm basically
> guessing now).  Will it work?  Is there a backward-compatibility issue
> here?

The above paragraph maybe cleared this up. The hibernate code will
still happily do I/O to any region handed to it by the swap code. That
could be a region already peppered with active swap (the normal case
today), or a NOSWAP region which swap otherwise stays out of (but
still manages). If we did swapoff and swapon with a different setting
for NOSWAP, that should all work fine, since hibernate leaves it to
the swapfile code to be in charge of sector allocs/frees.

There shouldn't be any backward compatibility issues because
SWAP_FLAGS_VALID enforced that usermode had been keeping the
unallocated bits as 0.

-Evan