From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EE583C433ED for ; Thu, 22 Apr 2021 13:08:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6A54E613C3 for ; Thu, 22 Apr 2021 13:08:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6A54E613C3 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D10F46B006E; Thu, 22 Apr 2021 09:08:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CC1F46B0070; Thu, 22 Apr 2021 09:08:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B4F1E6B0071; Thu, 22 Apr 2021 09:08:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0177.hostedemail.com [216.40.44.177]) by kanga.kvack.org (Postfix) with ESMTP id 952F16B006E for ; Thu, 22 Apr 2021 09:08:33 -0400 (EDT) Received: from smtpin32.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 42A501E1E for ; Thu, 22 Apr 2021 13:08:33 +0000 (UTC) X-FDA: 78060032106.32.1EB9014 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf18.hostedemail.com (Postfix) with ESMTP id B95FF200025C for ; Thu, 22 Apr 2021 13:08:34 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1619096911; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ziDd39JRIdWlI/ZncRHR4tPeHFque6IN9ySODF6A6RA=; b=ASiXiYpuhQJ/g3mUwmNQ88KUW3PYI8bbiUz8frlVc4HfAQOrx6zcEuPvAWLydBPThzX1G2 mZw1c82Q3w+yMMZ8mF25AIjIRzZApPejrKxB7Dsc17Ce3QtjfOdmwhrc1q8d63JSizP5iT EVok/PSjPGn9pOzVtaBHjrwaBxnCJgs= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id AE617B00E; Thu, 22 Apr 2021 13:08:31 +0000 (UTC) Date: Thu, 22 Apr 2021 15:08:31 +0200 From: Michal Hocko To: peter enderborg Cc: Shakeel Butt , Johannes Weiner , Roman Gushchin , Linux MM , Andrew Morton , Cgroups , David Rientjes , LKML , Suren Baghdasaryan , Greg Thelen , Dragos Sbirlea , Priya Duraisamy Subject: Re: [RFC] memory reserve for userspace oom-killer Message-ID: References: <699e51ba-825d-b243-8205-4d8cff478a66@sony.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <699e51ba-825d-b243-8205-4d8cff478a66@sony.com> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: B95FF200025C X-Stat-Signature: dec8rb869etk969shmkfpssc5kpy5zk1 Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf18; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1619096914-666525 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed 21-04-21 19:05:49, peter enderborg wrote: [...] > I think this is the wrong way to go. >=20 > I sent a patch for android lowmemorykiller some years ago. >=20 > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2017-= February/100319.html >=20 > 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 th= ough. >=20 > I don't think vmpressure and psi is that relevant now. (They are what u= serspace act on)=A0 But the basic idea is to have a priority queue > within the kernel. It need pick up new processes and dying process.=A0 = And then it has a order, and that > is set with oom adj values by activity manager in android.=A0 I see thi= s model can be reused for > something that is between a standard oom and userspace.=A0 Instead of v= mpressure and psi > a watchdog might be a better way.=A0 If userspace (in android the activ= ity manager or lmkd) does not kick the watchdog, > the watchdog bite the task according to the priority and kills it.=A0 T= his priority list does not have to be a list generated=A0 > within kernel. But it has the advantage that you inherent parents prope= rties.=A0 We use a rb-tree for that. >=20 > All that is missing is the watchdog. And this is off topic to the discussion as well. We are not discussing how to handle OOM situation best. Shakeel has brought up challenges that some userspace based OOM killer implementations are facing. Like it or not but different workloads have different requirements and what you are using in Android might not be the best fit for everybody. I will not comment on the android approach but it doesn't address any of the concerns that have been brought up. --=20 Michal Hocko SUSE Labs