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 15FABC433DF for ; Fri, 21 Aug 2020 04:43:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D5F582075E for ; Fri, 21 Aug 2020 04:43:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D5F582075E 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 677EA8D000A; Fri, 21 Aug 2020 00:43:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5FFC48D0005; Fri, 21 Aug 2020 00:43:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C7FA8D000A; Fri, 21 Aug 2020 00:43:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0131.hostedemail.com [216.40.44.131]) by kanga.kvack.org (Postfix) with ESMTP id 3041D8D0005 for ; Fri, 21 Aug 2020 00:43:18 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id E797A3633 for ; Fri, 21 Aug 2020 04:43:17 +0000 (UTC) X-FDA: 77173331634.06.grape78_2215bcf27036 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin06.hostedemail.com (Postfix) with ESMTP id B12F21004583B for ; Fri, 21 Aug 2020 04:43:17 +0000 (UTC) X-HE-Tag: grape78_2215bcf27036 X-Filterd-Recvd-Size: 6736 Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Fri, 21 Aug 2020 04:43:16 +0000 (UTC) Received: from in01.mta.xmission.com ([166.70.13.51]) by out02.mta.xmission.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1k8ytK-008psA-Jl; Thu, 20 Aug 2020 22:43:02 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1k8ytJ-00009U-Oh; Thu, 20 Aug 2020 22:43:02 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Michal Hocko Cc: Suren Baghdasaryan , Tetsuo Handa , Christian Brauner , Tim Murray , mingo@kernel.org, Peter Zijlstra , Thomas Gleixner , esyr@redhat.com, christian@kellner.me, areber@redhat.com, Shakeel Butt , cyphar@cyphar.com, Oleg Nesterov , adobriyan@gmail.com, Andrew Morton , gladkov.alexey@gmail.com, Michel Lespinasse , daniel.m.jordan@oracle.com, avagin@gmail.com, bernd.edlinger@hotmail.de, John Johansen , laoar.shao@gmail.com, Minchan Kim , kernel-team , LKML , linux-fsdevel@vger.kernel.org, linux-mm References: <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> <20200820162645.GP5033@dhcp22.suse.cz> Date: Thu, 20 Aug 2020 23:39:25 -0500 In-Reply-To: <20200820162645.GP5033@dhcp22.suse.cz> (Michal Hocko's message of "Thu, 20 Aug 2020 18:26:45 +0200") Message-ID: <87r1s0txxe.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=1k8ytJ-00009U-Oh;;;mid=<87r1s0txxe.fsf@x220.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18uBSxl8pJIjuyaXaco3WG9+jz0MdU4UDc= 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 in01.mta.xmission.com) X-Rspamd-Queue-Id: B12F21004583B X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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: Michal Hocko writes: > On Thu 20-08-20 08:56:53, Suren Baghdasaryan wrote: > [...] >> Catching up on the discussion which was going on while I was asleep... >> So it sounds like there is a consensus that oom_adj should be moved to >> mm_struct rather than trying to synchronize it among tasks sharing mm. >> That sounds reasonable to me too. Michal answered all the earlier >> questions about this patch, so I won't be reiterating them, thanks >> Michal. If any questions are still lingering about the original patch >> I'll be glad to answer them. > > I think it still makes some sense to go with a simpler (aka less tricky) > solution which would be your original patch with an incremental fix for > vfork and the proper ordering (http://lkml.kernel.org/r/20200820124109.GI5033@dhcp22.suse.cz) > and then make a more complex shift to mm struct on top of that. The > former will be less tricky to backport to stable IMHO. So I am confused. I don't know how a subtle dependency on something in clone is better than something flat footed in exec. That said if we are going for a small change why not: /* * Make sure we will check other processes sharing the mm if this is * not vfrok which wants its own oom_score_adj. * pin the mm so it doesn't go away and get reused after task_unlock */ if (!task->vfork_done) { struct task_struct *p = find_lock_task_mm(task); if (p) { - if (atomic_read(&p->mm->mm_users) > 1) { + if (atomic_read(&p->mm->mm_users) > p->signal->nr_threads) { mm = p->mm; mmgrab(mm); } task_unlock(p); } } That would seem to be the minimal change to make this happen. That has the advantage that if a processes does vfork it won't always have to take the slow path. Moving to the mm_struct is much less racy but this is simple. Eric