On Thu, Oct 17, 2019 at 3:55 PM Luigi Semenzato <semenzato@xxxxxxxxxx> wrote: > > To make hibernation work, I have been playing with this suggestion: > > > 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. > > What's a good way of swapping out 50% of RAM? I have tried playing > with /proc/sys/vm/min_free_kbytes. Lowering it below MemFree forces > reclaim and gets swapping started. Unfortunately the reclaim also > hits file pages, so badly that the system thrashes to a grinding halt. > Swappiness is already set to 100. Internally it seems that values up > to 200 are valid, and I wish that the entire range was allowed, but I > am not sure it would help. Right now I am playing with the production > kernel, but similar situations triggered the same behavior in the > Chrome OS kernels, even after internally setting swappiness to values > close to 200. One more data point: playing with min_free_kbytes is flakey: it can cause OOM-kills even when I increase it slowly (so that I don't completely destroy the file RSS) and there is plenty of swap space available. Not sure why. Is there perhaps a way of achieving this using the userland suspend API? If there is, I am not able to see it. Thanks! > On Tue, Oct 8, 2019 at 1:10 PM Luigi Semenzato <semenzato@xxxxxxxxxx> wrote: > > > > Actually, I think we only need to change the MM watermarks before > > hibernation and after resume. There's a patch that will do just that: > > > > https://lkml.org/lkml/2013/2/17/210 > > > > It didn't make it into mainline (which seems kind of unreasonable, > > since the watermarks themselves are based on heuristics) but shouldn't > > be difficult to apply. Or are there simpler solutions? > > > > On Tue, Oct 8, 2019 at 9:18 AM Luigi Semenzato <semenzato@xxxxxxxxxx> wrote: > > > > > > 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@xxxxxxxxxx> wrote: > > > > > > > > On Tue, Oct 8, 2019 at 5:26 PM Luigi Semenzato <semenzato@xxxxxxxxxx> 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.
