From: Shakeel Butt <shakeelb@google.com> To: Michal Hocko <mhocko@suse.com> Cc: Johannes Weiner <hannes@cmpxchg.org>, Roman Gushchin <guro@fb.com>, Linux MM <linux-mm@kvack.org>, Andrew Morton <akpm@linux-foundation.org>, Cgroups <cgroups@vger.kernel.org>, David Rientjes <rientjes@google.com>, LKML <linux-kernel@vger.kernel.org>, Suren Baghdasaryan <surenb@google.com>, Greg Thelen <gthelen@google.com>, Dragos Sbirlea <dragoss@google.com>, Priya Duraisamy <padmapriyad@google.com> Subject: Re: [RFC] memory reserve for userspace oom-killer Date: Tue, 4 May 2021 17:37:32 -0700 [thread overview] Message-ID: <CALvZod4_L7GSHnivQTSdDzo=fb4i3z=katjzVCHfLz9WWGK8uQ@mail.gmail.com> (raw) In-Reply-To: <YIA2rB0wgqKzfUfi@dhcp22.suse.cz> On Wed, Apr 21, 2021 at 7:29 AM Michal Hocko <mhocko@suse.com> wrote: > [...] > > > What if the pool is depleted? > > > > This would mean that either the estimate of mempool size is bad or > > oom-killer is buggy and leaking memory. > > > > I am open to any design directions for mempool or some other way where > > we can provide a notion of memory guarantee to oom-killer. > > OK, thanks for clarification. There will certainly be hard problems to > sort out[1] but the overall idea makes sense to me and it sounds like a > much better approach than a OOM specific solution. > > > [1] - how the pool is going to be replenished without hitting all > potential reclaim problems (thus dependencies on other all tasks > directly/indirectly) yet to not rely on any background workers to do > that on the task behalf without a proper accounting etc... > -- I am currently contemplating between two paths here: First, the mempool, exposed through either prctl or a new syscall. Users would need to trace their userspace oom-killer (or whatever their use case is) to find an appropriate mempool size they would need and periodically refill the mempools if allowed by the state of the machine. The challenge here is to find a good value for the mempool size and coordinating the refilling of mempools. Second is a mix of Roman and Peter's suggestions but much more simplified. A very simple watchdog with a kill-list of processes and if userspace didn't pet the watchdog within a specified time, it will kill all the processes in the kill-list. The challenge here is to maintain/update the kill-list. I would prefer the direction which oomd and lmkd are open to adopt. Any suggestions?
WARNING: multiple messages have this Message-ID (diff)
From: Shakeel Butt <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> To: Michal Hocko <mhocko-IBi9RG/b67k@public.gmane.org> Cc: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>, Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org>, Linux MM <linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>, Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>, Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Suren Baghdasaryan <surenb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Greg Thelen <gthelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Dragos Sbirlea <dragoss-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Priya Duraisamy <padmapriyad-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> Subject: Re: [RFC] memory reserve for userspace oom-killer Date: Tue, 4 May 2021 17:37:32 -0700 [thread overview] Message-ID: <CALvZod4_L7GSHnivQTSdDzo=fb4i3z=katjzVCHfLz9WWGK8uQ@mail.gmail.com> (raw) In-Reply-To: <YIA2rB0wgqKzfUfi-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org> On Wed, Apr 21, 2021 at 7:29 AM Michal Hocko <mhocko-IBi9RG/b67k@public.gmane.org> wrote: > [...] > > > What if the pool is depleted? > > > > This would mean that either the estimate of mempool size is bad or > > oom-killer is buggy and leaking memory. > > > > I am open to any design directions for mempool or some other way where > > we can provide a notion of memory guarantee to oom-killer. > > OK, thanks for clarification. There will certainly be hard problems to > sort out[1] but the overall idea makes sense to me and it sounds like a > much better approach than a OOM specific solution. > > > [1] - how the pool is going to be replenished without hitting all > potential reclaim problems (thus dependencies on other all tasks > directly/indirectly) yet to not rely on any background workers to do > that on the task behalf without a proper accounting etc... > -- I am currently contemplating between two paths here: First, the mempool, exposed through either prctl or a new syscall. Users would need to trace their userspace oom-killer (or whatever their use case is) to find an appropriate mempool size they would need and periodically refill the mempools if allowed by the state of the machine. The challenge here is to find a good value for the mempool size and coordinating the refilling of mempools. Second is a mix of Roman and Peter's suggestions but much more simplified. A very simple watchdog with a kill-list of processes and if userspace didn't pet the watchdog within a specified time, it will kill all the processes in the kill-list. The challenge here is to maintain/update the kill-list. I would prefer the direction which oomd and lmkd are open to adopt. Any suggestions?
next prev parent reply other threads:[~2021-05-05 0:37 UTC|newest] Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-20 1:44 [RFC] memory reserve for userspace oom-killer Shakeel Butt 2021-04-20 1:44 ` Shakeel Butt 2021-04-20 1:44 ` Shakeel Butt 2021-04-20 6:45 ` Michal Hocko 2021-04-20 6:45 ` Michal Hocko 2021-04-20 16:04 ` Shakeel Butt 2021-04-20 16:04 ` Shakeel Butt 2021-04-20 16:04 ` Shakeel Butt 2021-04-21 7:16 ` Michal Hocko 2021-04-21 7:16 ` Michal Hocko 2021-04-21 13:57 ` Shakeel Butt 2021-04-21 13:57 ` Shakeel Butt 2021-04-21 13:57 ` Shakeel Butt 2021-04-21 14:29 ` Michal Hocko 2021-04-22 12:33 ` [RFC PATCH] Android OOM helper proof of concept peter enderborg 2021-04-22 12:33 ` peter enderborg 2021-04-22 13:03 ` Michal Hocko 2021-05-05 0:37 ` Shakeel Butt [this message] 2021-05-05 0:37 ` [RFC] memory reserve for userspace oom-killer Shakeel Butt 2021-05-05 0:37 ` Shakeel Butt 2021-05-05 1:26 ` Suren Baghdasaryan 2021-05-05 1:26 ` Suren Baghdasaryan 2021-05-05 2:45 ` Shakeel Butt 2021-05-05 2:45 ` Shakeel Butt 2021-05-05 2:45 ` Shakeel Butt 2021-05-05 2:59 ` Suren Baghdasaryan 2021-05-05 2:59 ` Suren Baghdasaryan 2021-05-05 2:59 ` Suren Baghdasaryan 2021-05-05 2:43 ` Hillf Danton 2021-04-20 19:17 ` Roman Gushchin 2021-04-20 19:17 ` Roman Gushchin 2021-04-20 19:36 ` Suren Baghdasaryan 2021-04-20 19:36 ` Suren Baghdasaryan 2021-04-20 19:36 ` Suren Baghdasaryan 2021-04-21 1:18 ` Shakeel Butt 2021-04-21 1:18 ` Shakeel Butt 2021-04-21 1:18 ` Shakeel Butt 2021-04-21 2:58 ` Roman Gushchin 2021-04-21 13:26 ` Shakeel Butt 2021-04-21 13:26 ` Shakeel Butt 2021-04-21 13:26 ` Shakeel Butt 2021-04-21 19:04 ` Roman Gushchin 2021-04-21 19:04 ` Roman Gushchin 2021-04-21 7:23 ` Michal Hocko 2021-04-21 7:23 ` Michal Hocko 2021-04-21 14:13 ` Shakeel Butt 2021-04-21 14:13 ` Shakeel Butt 2021-04-21 14:13 ` Shakeel Butt 2021-04-21 17:05 ` peter enderborg 2021-04-21 18:28 ` Shakeel Butt 2021-04-21 18:28 ` Shakeel Butt 2021-04-21 18:28 ` Shakeel Butt 2021-04-21 18:46 ` Peter.Enderborg 2021-04-21 18:46 ` Peter.Enderborg-7U/KSKJipcs 2021-04-21 19:18 ` Shakeel Butt 2021-04-21 19:18 ` Shakeel Butt 2021-04-21 19:18 ` Shakeel Butt 2021-04-22 5:38 ` Peter.Enderborg 2021-04-22 5:38 ` Peter.Enderborg-7U/KSKJipcs 2021-04-22 14:27 ` Shakeel Butt 2021-04-22 14:27 ` Shakeel Butt 2021-04-22 14:27 ` Shakeel Butt 2021-04-22 15:41 ` Peter.Enderborg 2021-04-22 15:41 ` Peter.Enderborg-7U/KSKJipcs 2021-04-22 13:08 ` Michal Hocko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CALvZod4_L7GSHnivQTSdDzo=fb4i3z=katjzVCHfLz9WWGK8uQ@mail.gmail.com' \ --to=shakeelb@google.com \ --cc=akpm@linux-foundation.org \ --cc=cgroups@vger.kernel.org \ --cc=dragoss@google.com \ --cc=gthelen@google.com \ --cc=guro@fb.com \ --cc=hannes@cmpxchg.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@suse.com \ --cc=padmapriyad@google.com \ --cc=rientjes@google.com \ --cc=surenb@google.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.