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=-4.0 required=3.0 tests=BAYES_00,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 6F19AC433E3 for ; Thu, 16 Jul 2020 06:08:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3D0CA20578 for ; Thu, 16 Jul 2020 06:08:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3D0CA20578 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 E15026B0006; Thu, 16 Jul 2020 02:08:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DC4BD6B0007; Thu, 16 Jul 2020 02:08:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D02696B0008; Thu, 16 Jul 2020 02:08:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0133.hostedemail.com [216.40.44.133]) by kanga.kvack.org (Postfix) with ESMTP id BB5B96B0006 for ; Thu, 16 Jul 2020 02:08:18 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 81E462DFA for ; Thu, 16 Jul 2020 06:08:18 +0000 (UTC) X-FDA: 77042909076.02.bear46_5d039cb26eff Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin02.hostedemail.com (Postfix) with ESMTP id 69E461000AF4E536 for ; Thu, 16 Jul 2020 06:08:18 +0000 (UTC) X-HE-Tag: bear46_5d039cb26eff X-Filterd-Recvd-Size: 4521 Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Thu, 16 Jul 2020 06:08:17 +0000 (UTC) Received: by mail-wm1-f67.google.com with SMTP id 17so9798831wmo.1 for ; Wed, 15 Jul 2020 23:08:17 -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=fA5tWdiLhNa7nS+GyT1eM2qw5gievp5+cL4nuRfjYso=; b=HzkH/G2I8Q8GrnSXiAOwVLGKq35aSAaPOYovnbA7aelvKwEqctbz9Y6n0pPIl9wmtw mP+14/tm2hCDi7h0unX/RlL5dCjXKjc6aoV7CoYFKssP5aVKdUgmLl+Cp0KL4XtxtTBf Z9uG44/IlLDPqFA9sbTNZOSyez/COaqU+Fu49DAtn1j9s8JL2sBukrzgoO6RIsaKLaoe XMleGJlTkbMJcFxRLLpfDH16cFijfD8OLqPrQvoIVG8iHz9Ykz44bUCiaVsiq1HusrOb IRokdPFMNCpGX2MlJ9a089N4HXRXLytn8OS/V0GADHPphH2AuFJf/ePGao8aZl7S4X+D RvGQ== X-Gm-Message-State: AOAM533sWH/wQzx/RMWv0Oq7arJWClC0zTpRGjjQmagujJ54JFGeUaHP Vk52I8DC/HCBaB1BrWzaK2o= X-Google-Smtp-Source: ABdhPJycQoTpdPdxgaRu2xghVVuONgAJsqUndnhELnS0xohuk9rUb56auVmpiUWOVuaSwsD9NIpLHA== X-Received: by 2002:a1c:2402:: with SMTP id k2mr2806133wmk.138.1594879696937; Wed, 15 Jul 2020 23:08:16 -0700 (PDT) Received: from localhost (ip-37-188-169-187.eurotel.cz. [37.188.169.187]) by smtp.gmail.com with ESMTPSA id u84sm6636105wmg.7.2020.07.15.23.08.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jul 2020 23:08:16 -0700 (PDT) Date: Thu, 16 Jul 2020 08:08:14 +0200 From: Michal Hocko To: David Rientjes Cc: Yafang Shao , Tetsuo Handa , Andrew Morton , Johannes Weiner , Linux MM Subject: Re: [PATCH v2] memcg, oom: check memcg margin for parallel oom Message-ID: <20200716060814.GA31089@dhcp22.suse.cz> References: <1594735034-19190-1-git-send-email-laoar.shao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 69E461000AF4E536 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 Wed 15-07-20 10:30:51, David Rientjes wrote: [...] > I don't think moving the mem_cgroup_margin() check to out_of_memory() > right before printing the oom info and killing the process is a very > invasive patch. Any strong preference against doing it that way? I think > moving the check as late as possible to save a process from being killed > when racing with an exiter or killed process (including perhaps current) > has a pretty clear motivation. We have been through this discussion several times in the past IIRC The conclusion has been that the allocator (charging path for the memcg) is the one to define OOM situation. This is an inherently racy situation as long as we are not synchronizing oom with the world, which I believe we agree, we do not want to do. There are few exceptions to bail out early from the oom under certain situations and the trend was to remove some of the existing ones rather than adding new because they had subtle side effects and were prone to lockups. As much as it might sound attractive to move mem_cgroup_margin resp. last allocation attempt closer to the actual oom killing I haven't seen any convincing data that would support that such a change would make a big difference. select_bad_process is not a free operation as it scales with the number of tasks in the oom domain but it shouldn't be a super expensive. The oom reporting is by far the most expensive part of the operation. That being said, really convincing data should be presented in order to do such a change. I do not think we want to do that just in case. -- Michal Hocko SUSE Labs