From: Shakeel Butt <shakeelb@google.com> To: peter enderborg <peter.enderborg@sony.com> Cc: Johannes Weiner <hannes@cmpxchg.org>, Roman Gushchin <guro@fb.com>, Michal Hocko <mhocko@kernel.org>, 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: Wed, 21 Apr 2021 11:28:38 -0700 [thread overview] Message-ID: <CALvZod7AEjzWa6AR4Ym1jpfzT32hmepxvci6hXvNJTEQvcQqEw@mail.gmail.com> (raw) In-Reply-To: <699e51ba-825d-b243-8205-4d8cff478a66@sony.com> On Wed, Apr 21, 2021 at 10:06 AM peter enderborg <peter.enderborg@sony.com> wrote: > > On 4/20/21 3:44 AM, Shakeel Butt wrote: [...] > > I think this is the wrong way to go. Which one? Are you talking about the kernel one? We already talked out of that. To decide to OOM, we need to look at a very diverse set of metrics and it seems like that would be very hard to do flexibly inside the kernel. > > I sent a patch for android lowmemorykiller some years ago. > > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2017-February/100319.html > > It has been improved since than, so it can act handle oom callbacks, it can act on vmpressure and psi > and as a shrinker. The patches has not been ported to resent kernels though. > > I don't think vmpressure and psi is that relevant now. (They are what userspace act on) But the basic idea is to have a priority queue > within the kernel. It need pick up new processes and dying process. And then it has a order, and that > is set with oom adj values by activity manager in android. I see this model can be reused for > something that is between a standard oom and userspace. Instead of vmpressure and psi > a watchdog might be a better way. If userspace (in android the activity manager or lmkd) does not kick the watchdog, > the watchdog bite the task according to the priority and kills it. This priority list does not have to be a list generated > within kernel. But it has the advantage that you inherent parents properties. We use a rb-tree for that. > > All that is missing is the watchdog. > Actually no. It is missing the flexibility to monitor metrics which a user care and based on which they decide to trigger oom-kill. Not sure how will watchdog replace psi/vmpressure? Userspace keeps petting the watchdog does not mean that system is not suffering. In addition oom priorities change dynamically and changing it in your system seems very hard. Cgroup awareness is missing too. Anyways, there are already widely deployed userspace oom-killer solutions (lmkd, oomd). I am aiming to further improve the reliability.
WARNING: multiple messages have this Message-ID (diff)
From: Shakeel Butt <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> To: peter enderborg <peter.enderborg-7U/KSKJipcs@public.gmane.org> Cc: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>, Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org>, Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@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: Wed, 21 Apr 2021 11:28:38 -0700 [thread overview] Message-ID: <CALvZod7AEjzWa6AR4Ym1jpfzT32hmepxvci6hXvNJTEQvcQqEw@mail.gmail.com> (raw) In-Reply-To: <699e51ba-825d-b243-8205-4d8cff478a66-7U/KSKJipcs@public.gmane.org> On Wed, Apr 21, 2021 at 10:06 AM peter enderborg <peter.enderborg-7U/KSKJipcs@public.gmane.org> wrote: > > On 4/20/21 3:44 AM, Shakeel Butt wrote: [...] > > I think this is the wrong way to go. Which one? Are you talking about the kernel one? We already talked out of that. To decide to OOM, we need to look at a very diverse set of metrics and it seems like that would be very hard to do flexibly inside the kernel. > > I sent a patch for android lowmemorykiller some years ago. > > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2017-February/100319.html > > It has been improved since than, so it can act handle oom callbacks, it can act on vmpressure and psi > and as a shrinker. The patches has not been ported to resent kernels though. > > I don't think vmpressure and psi is that relevant now. (They are what userspace act on) But the basic idea is to have a priority queue > within the kernel. It need pick up new processes and dying process. And then it has a order, and that > is set with oom adj values by activity manager in android. I see this model can be reused for > something that is between a standard oom and userspace. Instead of vmpressure and psi > a watchdog might be a better way. If userspace (in android the activity manager or lmkd) does not kick the watchdog, > the watchdog bite the task according to the priority and kills it. This priority list does not have to be a list generated > within kernel. But it has the advantage that you inherent parents properties. We use a rb-tree for that. > > All that is missing is the watchdog. > Actually no. It is missing the flexibility to monitor metrics which a user care and based on which they decide to trigger oom-kill. Not sure how will watchdog replace psi/vmpressure? Userspace keeps petting the watchdog does not mean that system is not suffering. In addition oom priorities change dynamically and changing it in your system seems very hard. Cgroup awareness is missing too. Anyways, there are already widely deployed userspace oom-killer solutions (lmkd, oomd). I am aiming to further improve the reliability.
next prev parent reply other threads:[~2021-04-21 18:28 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 ` [RFC] memory reserve for userspace oom-killer Shakeel Butt 2021-05-05 0:37 ` 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 [this message] 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=CALvZod7AEjzWa6AR4Ym1jpfzT32hmepxvci6hXvNJTEQvcQqEw@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@kernel.org \ --cc=padmapriyad@google.com \ --cc=peter.enderborg@sony.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.