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.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 75749C433DF for ; Thu, 20 Aug 2020 15:08:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 39EA9208C7 for ; Thu, 20 Aug 2020 15:08:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 39EA9208C7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ubuntu.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CD7846B000E; Thu, 20 Aug 2020 11:07:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C8C276B0010; Thu, 20 Aug 2020 11:07:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BC5356B0022; Thu, 20 Aug 2020 11:07:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0241.hostedemail.com [216.40.44.241]) by kanga.kvack.org (Postfix) with ESMTP id A726D6B000E for ; Thu, 20 Aug 2020 11:07:59 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 623688248068 for ; Thu, 20 Aug 2020 15:07:59 +0000 (UTC) X-FDA: 77171277078.04.mist72_110952c27031 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id D00CF800843E for ; Thu, 20 Aug 2020 15:07:55 +0000 (UTC) X-HE-Tag: mist72_110952c27031 X-Filterd-Recvd-Size: 5085 Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Thu, 20 Aug 2020 15:07:41 +0000 (UTC) Received: from ip5f5af70b.dynamic.kabel-deutschland.de ([95.90.247.11] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1k8m9Y-0005rd-Um; Thu, 20 Aug 2020 15:06:57 +0000 Date: Thu, 20 Aug 2020 17:06:55 +0200 From: Christian Brauner To: "Eric W. Biederman" Cc: Tetsuo Handa , Michal Hocko , 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: <20200820150655.ewjqommxs3axrsf6@wittgenstein> References: <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> <637ab0e7-e686-0c94-753b-b97d24bb8232@i-love.sakura.ne.jp> <87k0xtv0d4.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87k0xtv0d4.fsf@x220.int.ebiederm.org> X-Rspamd-Queue-Id: D00CF800843E 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, Aug 20, 2020 at 09:49:11AM -0500, Eric W. Biederman wrote: > Tetsuo Handa writes: > > > On 2020/08/20 23:00, 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 > >> > >> 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, 44a70adec910 is trying to go towards changing from a property of the task/thread-group > > to a property of mm. But I don't think we need to do it at the cost of "__set_oom_adj() latency > > Yong-Taek Lee and Tim Murray have reported" and "complicity for supporting > > vfork() => __set_oom_adj() => execve() sequence". > > The thing is commit 44a70adec910d692 ("mm, oom_adj: make sure processes > sharing mm have same view of oom_score_adj") has been in the tree for 4 > years. > > That someone is just now noticing a regression is their problem. The > change is semantics is done and decided. We can not reasonably revert > at this point without risking other regressions. > > Given that the decision has already been made to make oom_adj > effectively per mm. There is no point on have a debate if we should do > it. I mean yeah, I think no-one really was going to jump on the revert-train. At least for me the historical background was quite important to know actually. The fact that by sharing the mm one can effectively be bound to the oom score of another thread-group is kinda suprising and the oom_score_adj section in man proc doesn't mention this. And I really think we need to document this. Either on the clone() or on the oom_score_adj page... Christian