I was forgetting: forcing swap by eating up memory is dangerous because it can lead to unexpected OOM kills, 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. On Thu, Feb 20, 2020 at 9:16 AM Luigi Semenzato <semenzato@xxxxxxxxxx> wrote: > > I think this is the right group for the memory issues. > > I suspect that the problem with failed allocations (ENOMEM) boils down > to the unreliability of the page allocator. In my experience, under > pressure (i.e. pages must be swapped out to be reclaimed) allocations > can fail even when in theory they should succeed. (I wish I were > wrong and that someone would convincingly correct me.) > > I have a workaround in which I use memcgroups to free pages before > starting hibernation. The cgroup request "echo $limit > > .../memory.limit_in_bytes" blocks until memory usage in the chosen > cgroup is below $limit. However, I have seen this request fail even > when there is extra available swap space. > > The callback for the operation is mem_cgroup_resize_limit() (BTW I am > looking at kernel version 4.3.5) and that code has a loop where > try_to_free_pages() is called up to retry_count, which is at least 5. > Why 5? One suspects that the writer of that code must have also > realized that the page freeing request is unreliable and it's worth > trying multiple times. > > So you could try something similar. I don't know if there are > interfaces to try_to_free_pages() other than those in cgroups. If > not, and you aren't using cgroups, one way might be to start several > memory-eating processes (such as "dd if=/dev/zero bs=1G count=1 | > sleep infinity") and monitor allocation, then when they use more than > 50% of RAM kill them and immediately hibernate before the freed pages > are reused. If you can build your custom kernel, maybe it's worth > adding a sysfs entry to invoke try_to_free_pages(). You could also > change the hibernation code to do that, but having the user-level hook > may be more flexible. > > > On Wed, Feb 19, 2020 at 6:56 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > > > Also, is this the correct list for hibernation/swap discussion? Or linux-pm@? > > > > Thanks, > > > > Chris Murphy
