Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190310203403.27915-1-sultan@kerneltoast.com>
 <20190311174320.GC5721@dhcp22.suse.cz> <20190311175800.GA5522@sultan-box.localdomain>
In-Reply-To: <20190311175800.GA5522@sultan-box.localdomain>
From:   Suren Baghdasaryan <surenb@google.com>
Date:   Mon, 11 Mar 2019 13:10:36 -0700
Message-ID: <CAJuCfpHTjXejo+u--3MLZZj7kWQVbptyya4yp1GLE3hB=BBX7w@mail.gmail.com>
Subject: Re: [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android
To:     Sultan Alsawaf <sultan@kerneltoast.com>
Cc:     Michal Hocko <mhocko@kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= <arve@android.com>,
        Todd Kjos <tkjos@android.com>,
        Martijn Coenen <maco@android.com>,
        Joel Fernandes <joel@joelfernandes.org>,
        Christian Brauner <christian@brauner.io>,
        Ingo Molnar <mingo@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        LKML <linux-kernel@vger.kernel.org>, devel@driverdev.osuosl.org,
        linux-mm <linux-mm@kvack.org>, Tim Murray <timmurray@google.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Sultan,

On Mon, Mar 11, 2019 at 10:58 AM Sultan Alsawaf <sultan@kerneltoast.com> wrote:
>
> On Mon, Mar 11, 2019 at 06:43:20PM +0100, Michal Hocko wrote:
> > I am sorry but we are not going to maintain two different OOM
> > implementations in the kernel. From a quick look the implementation is
> > quite a hack which is not really suitable for anything but a very
> > specific usecase. E.g. reusing a freed page for a waiting allocation
> > sounds like an interesting idea but it doesn't really work for many
> > reasons. E.g. any NUMA affinity is broken, zone protection doesn't work
> > either. Not to mention how the code hooks into the allocator hot paths.
> > This is simply no no.
> >
> > Last but not least people have worked really hard to provide means (PSI)
> > to do what you need in the userspace.
>
> Hi Michal,
>
> Thanks for the feedback. I had no doubt that this would be vehemently rejected
> on the mailing list, but I wanted feedback/opinions on it and thus sent it as anRFC.

Thanks for the proposal. I think Michal and Joel already answered why
in-kernel LMK will not be accepted and that was one of the reasons the
lowmemorykiller driver was removed in 4.12.

> At best I thought perhaps the mechanisms I've employed might serve as
> inspiration for LMKD improvements in Android, since this hacky OOM killer I've
> devised does work quite well for the very specific usecase it is set out to
> address. The NUMA affinity and zone protection bits are helpful insights too.

The idea seems interesting although I need to think about this a bit
more. Killing processes based on failed page allocation might backfire
during transient spikes in memory usage.
AFAIKT the biggest issue with using this approach in userspace is that
it's not practically implementable without heavy in-kernel support.
How to implement such interaction between kernel and userspace would
be an interesting discussion which I would be happy to participate in.

> I'll take a look at PSI which Joel mentioned as well.
>
> Thanks,
> Sultan Alsawaf

Thanks,
Suren.