Re: hibernation memory usage

[Luigi Semenzato <semenzato@google.com>]

Yes, that makes sense, thank you.  Use separate partitions for swap
and hibernation.

Normally the kernel starts swapping out when there's no reclaimable
memory, so anon usage will be high.  Do you think cranking up
/proc/vm/swappiness would be enough to ensure that file pages stay
over 50%?  Or would you use some tricks, such as running a
high-priority process which allocates >50% of RAM, thus forcing other
anon pages to be swapped out, then killing that process and quickly
hibernating before too many pages are brought back in?  Or changing
the kernel so that in the first part of hibernation we'll just swap
stuff out?

On Tue, Oct 8, 2019 at 8:39 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Tue, Oct 8, 2019 at 5:26 PM Luigi Semenzato <semenzato@google.com> wrote:
> >
> > Thank you for your reply!
> >
> > I understand the need for saving all state, not just process/task
> > state.  But for many of the systems that could benefit from
> > hibernation, the majority of RAM is taken by user processes (I am
> > thinking laptops).  It should be possible to copy their anonymous
> > pages to disk more or less directly, without making an extra copy like
> > it's done for all other pages.  I am not sure what happens with kernel
> > tasks, but they don't have anonymous pages (that I know).
> >
> > I am curious to know how/if hibernation is currently used in practice.
> > It doesn't seem practical to require that user processes take less
> > than 50% of RAM at all times.  There may be special cases in which the
> > restriction can be achieved by terminating non-essential processes
> > before hibernating, but I don't know of any.
> >
> > I would also like to know how much work it might take to avoid the
> > extra copy of the anonymous pages of frozen processes.
>
> Whatever doesn't fit into 50% of RAM needs to be swapped out before
> hibernation.  The efficiency of that depends on the swap handling code
> and the underlying hardware.  If that is efficient enough overall,
> trying to avoid it altogether isn't going to make much of a
> difference.