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 51DFBC433E1 for ; Thu, 20 Aug 2020 14:53:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1F0D02075E for ; Thu, 20 Aug 2020 14:53:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1F0D02075E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=xmission.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9346A8D002E; Thu, 20 Aug 2020 10:53:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8E4F48D0001; Thu, 20 Aug 2020 10:53:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7D4A58D002E; Thu, 20 Aug 2020 10:53:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0218.hostedemail.com [216.40.44.218]) by kanga.kvack.org (Postfix) with ESMTP id 684EF8D0001 for ; Thu, 20 Aug 2020 10:53:01 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 077FF8248068 for ; Thu, 20 Aug 2020 14:53:01 +0000 (UTC) X-FDA: 77171239362.09.elbow45_3a11a5527031 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin09.hostedemail.com (Postfix) with ESMTP id C47A7180AD806 for ; Thu, 20 Aug 2020 14:53:00 +0000 (UTC) X-HE-Tag: elbow45_3a11a5527031 X-Filterd-Recvd-Size: 6946 Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Thu, 20 Aug 2020 14:53:00 +0000 (UTC) Received: from in02.mta.xmission.com ([166.70.13.52]) by out01.mta.xmission.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1k8lvs-00Aq9f-QJ; Thu, 20 Aug 2020 08:52:48 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1k8lvr-0002V7-SF; Thu, 20 Aug 2020 08:52:48 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Tetsuo Handa Cc: Christian Brauner , 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 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> <637ab0e7-e686-0c94-753b-b97d24bb8232@i-love.sakura.ne.jp> Date: Thu, 20 Aug 2020 09:49:11 -0500 In-Reply-To: <637ab0e7-e686-0c94-753b-b97d24bb8232@i-love.sakura.ne.jp> (Tetsuo Handa's message of "Thu, 20 Aug 2020 23:18:40 +0900") Message-ID: <87k0xtv0d4.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1k8lvr-0002V7-SF;;;mid=<87k0xtv0d4.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19eJAV7OrO6lFoLS+9WugMFiMdwgaSwTyw= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH 1/1] mm, oom_adj: don't loop through tasks in __set_oom_adj when not necessary X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) X-Rspamd-Queue-Id: C47A7180AD806 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: 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. Eric