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=-7.0 required=3.0 tests=BAYES_00,INCLUDES_PATCH, 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 27C70C433E1 for ; Mon, 13 Jul 2020 19:06:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E7BC420738 for ; Mon, 13 Jul 2020 19:06:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E7BC420738 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5D7628D0002; Mon, 13 Jul 2020 15:06:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 588DF8D0001; Mon, 13 Jul 2020 15:06:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4771A8D0002; Mon, 13 Jul 2020 15:06:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0180.hostedemail.com [216.40.44.180]) by kanga.kvack.org (Postfix) with ESMTP id 32B668D0001 for ; Mon, 13 Jul 2020 15:06:03 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id CA5D42DFD for ; Mon, 13 Jul 2020 19:06:02 +0000 (UTC) X-FDA: 77033982564.03.turn87_5509fe626eea Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id 0735728A27A for ; Mon, 13 Jul 2020 19:05:48 +0000 (UTC) X-HE-Tag: turn87_5509fe626eea X-Filterd-Recvd-Size: 5575 Received: from mail-ej1-f65.google.com (mail-ej1-f65.google.com [209.85.218.65]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Mon, 13 Jul 2020 19:05:47 +0000 (UTC) Received: by mail-ej1-f65.google.com with SMTP id f12so18574076eja.9 for ; Mon, 13 Jul 2020 12:05:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=haYLBC8s322ZGjkE0yjJS3hn9/fCbRozsyOLAIi/C/4=; b=MhQ47IKSDC8oHjRtqXi4GHwPPsKD/pjrlwLBmXSKmpsl43BFFQrO5l9FGWOLjYJfFj 67X5ClOf24y8+W9GwlkzSTFmqeN7Ieo0lF2o5tIYj+Ovza22FzCID9SnRe1dJu92fNyi RbinWCdOdGIbcdSS2AMDTj2N2aR+fPpUIaThOiTGQMCk5ZWYAO8ss2fAjUGumNUIMpsc MIPVDxlndDdck4Eedxfi0P6VHOC6ZFLotTXaUMfhwMYrdVJ0ElnQpxdXy6UqRFs9FeEj VOSiiS7y4vilyOZOgNjBk/bfaJnKsw26amqGYW7Z82/Y3S31i9aGwSeH1Wsg/T9zNLmj vfRw== X-Gm-Message-State: AOAM530MAg9uwr7+B+B61AxE9gj3MXyLp0LIyzgnjYf/eQ4t6YbaRIk2 QMG6NZDgOXsVjtkRLzzsWTU= X-Google-Smtp-Source: ABdhPJxnyrbCBNlTLJVQmvmjPqP5bykybS/33nT6ec97m56NGpN9uy0HXABvQLHD3jgNATqsvLY28A== X-Received: by 2002:a17:906:2799:: with SMTP id j25mr1132946ejc.466.1594667146480; Mon, 13 Jul 2020 12:05:46 -0700 (PDT) Received: from localhost (ip-37-188-148-171.eurotel.cz. [37.188.148.171]) by smtp.gmail.com with ESMTPSA id u2sm12234584edq.29.2020.07.13.12.05.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Jul 2020 12:05:45 -0700 (PDT) Date: Mon, 13 Jul 2020 21:05:38 +0200 From: Michal Hocko To: Yafang Shao Cc: David Rientjes , Andrew Morton , Linux MM Subject: Re: [PATCH] mm, oom: don't invoke oom killer if current has been reapered Message-ID: <20200713190538.GG16783@dhcp22.suse.cz> References: <1594437481-11144-1-git-send-email-laoar.shao@gmail.com> <20200713060154.GA16783@dhcp22.suse.cz> <20200713062132.GB16783@dhcp22.suse.cz> <20200713124503.GF16783@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 0735728A27A 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: On Mon 13-07-20 21:11:50, Yafang Shao wrote: > On Mon, Jul 13, 2020 at 8:45 PM Michal Hocko wrote: > > > > On Mon 13-07-20 20:24:07, Yafang Shao wrote: [...] > > > But we can't try locking the global oom_lock here, because task ooming > > > in memcg foo may can't help the tasks in memcg bar. > > > > I do not follow. oom_lock is not about fwd progress. It is a big lock to > > synchronize against oom_disable logic. > > > > I have this in mind > > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > index 248e6cad0095..29d1f8c2d968 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -1563,8 +1563,10 @@ static bool mem_cgroup_out_of_memory(struct mem_cgroup *memcg, gfp_t gfp_mask, > > }; > > bool ret; > > > > - if (mutex_lock_killable(&oom_lock)) > > + if (!mutex_trylock(&oom_lock)) > > return true; > > root_mem_cgroup > / \ > memcg_a (16G) memcg_b (32G) > | | > process a_1 (reach memcg_a limit) process b_1(reach > memcg_b limit) > hold oom_lock wait oom_lock > > So we can find that process a_1 will try to kill process in memcg_a, > while process b_1 need to try to kill process in memcg_b. > IOW, the process killed in memcg_a can't help the processes in > memcg_b, so if process b_1 should not trylock oom_lock here. > > While if the memcg tree is , > target mem_cgroup (16G) > / \ > | > | > process a_1 (reach memcg_a limit) process a_2(reach > memcg_a limit) > hold oom_lock wait oom_lock > > Then, process a_2 can trylock oom_lock here. IOW, these processes > should in the same memcg. > > That's why I said that we should introduce per-memcg oom_lock. I still fail to understand your reaasoning. Sure, the oom lock is global so it doesn't have a per oom hierarchy resolution pretty much by definition. But that is not really important. The whole point of the trylock is to remove the ordering between the oom selection, the oom reaper and potential charge consumers which trigger the oom in parallel. With the blocking lock they would pile up in the order they have hit the OOM situation. With the trylock they would simply keep retrying until the oom is done. That would reduce the race window considerably. This is what the global oom is doing. Another alternative would be to check mem_cgroup_margin after the lock is taken but it would be better to keep in sync with the global case as much as possible unless there is a good reason to differ. -- Michal Hocko SUSE Labs