On Fri 21-02-20 10:04:18, Rafael J. Wysocki wrote: > On Fri, Feb 21, 2020 at 9:49 AM Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > > > On Thu 20-02-20 09:38:06, Luigi Semenzato wrote: > > > I was forgetting: forcing swap by eating up memory is dangerous > > > because it can lead to unexpected OOM kills > > > > Could you be more specific what you have in mind? swapoff causing the > > OOM killer? > > > > > , but you can mitigate that > > > by giving the memory-eaters a higher OOM kill score. Still, some way > > > of calling try_to_free_pages() directly from user-level would be > > > preferable. I wonder if such API has been discussed. > > > > No, there is no API to trigger the global memory reclaim. You could > > start the reclaim by increasing min_free_kbytes but I wouldn't really > > recommend that unless you know exactly what you are doing and also I > > fail to see the point. If s2disk fails due to insufficient swap space > > then how can a pro-active reclaim help in the first place? > > My understanding of the problem is that the size of swap is > (theoretically) sufficient, but it is not used as expected during the > preallocation of image memory. > > It was stated in one of the previous messages (not in this thread, > cannot find it now) that swap (of the same size as RAM) was activated > (swapon) right before hibernation, so theoretically that should be > sufficient AFAICS. Hmm, this is interesting. Let me have a closer look... pm_restrict_gfp_mask which would completely rule out any IO happens after hibernate_preallocate_memory is done and my limited understanding tells me that this is where all the reclaim happens (via shrink_all_memory). It is quite possible that the MM decides to not swap in that path - depending on the memory usage - and miss it's target. More details would be needed. E.g. vmscan tracepoints could tell us more. -- Michal Hocko SUSE Labs