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 27B6DC433DF for ; Fri, 21 Aug 2020 07:17:39 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DFA8120732 for ; Fri, 21 Aug 2020 07:17:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DFA8120732 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 80FCE8D001F; Fri, 21 Aug 2020 03:17:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 798878D0006; Fri, 21 Aug 2020 03:17:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 63AD28D001F; Fri, 21 Aug 2020 03:17:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0121.hostedemail.com [216.40.44.121]) by kanga.kvack.org (Postfix) with ESMTP id 4C00F8D0006 for ; Fri, 21 Aug 2020 03:17:38 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 0FAFF2464 for ; Fri, 21 Aug 2020 07:17:38 +0000 (UTC) X-FDA: 77173720596.18.robin21_500fac327037 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin18.hostedemail.com (Postfix) with ESMTP id D1C48100EC675 for ; Fri, 21 Aug 2020 07:17:33 +0000 (UTC) X-HE-Tag: robin21_500fac327037 X-Filterd-Recvd-Size: 4428 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Fri, 21 Aug 2020 07:17:33 +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 96A57AAC7; Fri, 21 Aug 2020 07:17:59 +0000 (UTC) Date: Fri, 21 Aug 2020 09:17:30 +0200 From: Michal Hocko To: "Eric W. Biederman" 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 Subject: Re: [PATCH 1/1] mm, oom_adj: don't loop through tasks in __set_oom_adj when not necessary Message-ID: <20200821071730.GA32537@dhcp22.suse.cz> References: <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> <87r1s0txxe.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r1s0txxe.fsf@x220.int.ebiederm.org> X-Rspamd-Queue-Id: D1C48100EC675 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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 23:39:25, Eric W. Biederman wrote: > 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. Well, I think that setting a flag is an easier approach than handle all the special cases for the mm thing. But this is likely because this is not my domain so my judgment call might be misled. Anyway if there is a general consensus that doing the middle step is not worth it I am not going to object. > 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); > } > } I remember playing with something like that but it had problems too. I do not remember details. Oleg would know better. -- Michal Hocko SUSE Labs