From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751357AbdBXOLw (ORCPT ); Fri, 24 Feb 2017 09:11:52 -0500 Received: from mx2.suse.de ([195.135.220.15]:59838 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751115AbdBXOLr (ORCPT ); Fri, 24 Feb 2017 09:11:47 -0500 Date: Fri, 24 Feb 2017 15:11:44 +0100 From: Michal Hocko To: peter enderborg Cc: Martijn Coenen , John Stultz , Greg KH , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Riley Andrews , devel@driverdev.osuosl.org, LKML , Linux-MM , Todd Kjos , Android Kernel Team , Rom Lemarchand , Tim Murray Subject: Re: [PATCH] staging, android: remove lowmemory killer from the tree Message-ID: <20170224141144.GI19161@dhcp22.suse.cz> References: <20170222120121.12601-1-mhocko@kernel.org> <855e929a-a891-a435-8f75-3674d8a3e96d@sonymobile.com> <20170224122830.GG19161@dhcp22.suse.cz> <9ffdcc79-12d4-00c5-182c-498b8ca951cc@sonymobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ffdcc79-12d4-00c5-182c-498b8ca951cc@sonymobile.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 24-02-17 14:16:34, peter enderborg wrote: > On 02/24/2017 01:28 PM, Michal Hocko wrote: [...] > > Yeah, I strongly believe that the chosen approach is completely wrong. > > Both in abusing the shrinker interface and abusing oom_score_adj as the > > only criterion for the oom victim selection. > > No one is arguing that shrinker is not problematic. And would be great > if it is removed from lmk. The oom_score_adj is the way user-space > tells the kernel what the user-space has as prio. And android is using > that very much. It's a core part. Is there any documentation which describes how this is done? > I have never seen it be used on > other linux system so what is the intended usage of oom_score_adj? Is > this really abusing? oom_score_adj is used to _adjust_ the calculated oom score. It is not a criterion on its own, well, except for the extreme sides of the range which are defined to enforce resp. disallow selecting the task. The global oom killer calculates the oom score as a function of the memory consumption. Your patch simply ignores the memory consumption (and uses pids to sort tasks with the same oom score which is just mind boggling) and that is what I call the abuse. The oom score calculation might change in future, of course, but all consumers of the oom_score_adj really have to agree on the base which is adjusted by this tunable otherwise you can see a lot of unexpected behavior. I would even argue that nobody outside of mm/oom_kill.c should really have any business with this tunable. You can of course tweak the value from the userspace and help to chose a better oom victim this way but that is it. Anyway, I guess we are getting quite off-topic here. -- Michal Hocko SUSE Labs