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.8 required=3.0 tests=BAYES_00, 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 AF01CC433E1 for ; Thu, 20 Aug 2020 14:15:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 79C5B20674 for ; Thu, 20 Aug 2020 14:15:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 79C5B20674 Authentication-Results: mail.kernel.org; dmarc=none (p=none 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 219088D002A; Thu, 20 Aug 2020 10:15:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1C9078D0002; Thu, 20 Aug 2020 10:15:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0B86F8D002A; Thu, 20 Aug 2020 10:15:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0179.hostedemail.com [216.40.44.179]) by kanga.kvack.org (Postfix) with ESMTP id E61D68D0002 for ; Thu, 20 Aug 2020 10:15:52 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 97D0F181AC9CB for ; Thu, 20 Aug 2020 14:15:52 +0000 (UTC) X-FDA: 77171145744.27.rate25_26167d127031 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id DFF883D8EC for ; Thu, 20 Aug 2020 14:15:41 +0000 (UTC) X-HE-Tag: rate25_26167d127031 X-Filterd-Recvd-Size: 4010 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Thu, 20 Aug 2020 14:15:40 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id B8435B883; Thu, 20 Aug 2020 14:16:06 +0000 (UTC) Date: Thu, 20 Aug 2020 16:15:38 +0200 From: Michal Hocko To: Christian Brauner Cc: Tetsuo Handa , "Eric W. Biederman" , Suren Baghdasaryan , timmurray@google.com, mingo@kernel.org, peterz@infradead.org, tglx@linutronix.de, esyr@redhat.com, christian@kellner.me, areber@redhat.com, shakeelb@google.com, cyphar@cyphar.com, oleg@redhat.com, adobriyan@gmail.com, akpm@linux-foundation.org, gladkov.alexey@gmail.com, walken@google.com, daniel.m.jordan@oracle.com, avagin@gmail.com, bernd.edlinger@hotmail.de, john.johansen@canonical.com, laoar.shao@gmail.com, minchan@kernel.org, kernel-team@android.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 1/1] mm, oom_adj: don't loop through tasks in __set_oom_adj when not necessary Message-ID: <20200820141538.GM5033@dhcp22.suse.cz> References: <20200820002053.1424000-1-surenb@google.com> <87zh6pxzq6.fsf@x220.int.ebiederm.org> <20200820124241.GJ5033@dhcp22.suse.cz> <87lfi9xz7y.fsf@x220.int.ebiederm.org> <87d03lxysr.fsf@x220.int.ebiederm.org> <20200820132631.GK5033@dhcp22.suse.cz> <20200820133454.ch24kewh42ax4ebl@wittgenstein> <20200820140054.fdkbotd4tgfrqpe6@wittgenstein> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200820140054.fdkbotd4tgfrqpe6@wittgenstein> X-Rspamd-Queue-Id: DFF883D8EC X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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 Thu 20-08-20 16:00:54, Christian Brauner wrote: > On Thu, Aug 20, 2020 at 10:48:43PM +0900, Tetsuo Handa wrote: > > On 2020/08/20 22:34, Christian Brauner wrote: > > > On Thu, Aug 20, 2020 at 03:26:31PM +0200, Michal Hocko wrote: > > >> If you can handle vfork by other means then I am all for it. There were > > >> no patches in that regard proposed yet. Maybe it will turn out simpler > > >> then the heavy lifting we have to do in the oom specific code. > > > > > > Eric's not wrong. I fiddled with this too this morning but since > > > oom_score_adj is fiddled with in a bunch of places this seemed way more > > > code churn then what's proposed here. > > > > I prefer simply reverting commit 44a70adec910d692 ("mm, oom_adj: make sure > > processes sharing mm have same view of oom_score_adj"). > > > > https://lore.kernel.org/patchwork/patch/1037208/ > > I guess this is a can of worms but just or the sake of getting more > background: the question seems to be whether the oom adj score is a > property of the task/thread-group or a property of the mm. I always > thought the oom score is a property of the task/thread-group and not the > mm which is also why it lives in struct signal_struct and not in struct > mm_struct. But I would tend to agree that from the userspace POV it is nice to look at oom tuning per process but fundamentaly the oom killer operates on the address space much more than other resources bound to a process because it is usually the address space hogging the largest portion of the memory footprint. This is the reason why the oom killer has been evaluating tasks based on that aspect rather than other potential memory consumers bound to a task. Mostly due to lack of means to evaluate those. > 44a70adec910 ("mm, oom_adj: make sure processes sharing mm have same view of oom_score_adj") > > reads like it is supposed to be a property of the mm or at least the > change makes it so. Yes, based on the current and historical behavior of the oom killer. -- Michal Hocko SUSE Labs