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=-1.0 required=3.0 tests=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 CB2BBC3A5A9 for ; Mon, 4 May 2020 16:11:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 94F07206D9 for ; Mon, 4 May 2020 16:11:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 94F07206D9 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 648938E0059; Mon, 4 May 2020 12:11:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F9368E0058; Mon, 4 May 2020 12:11:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 50FD28E0059; Mon, 4 May 2020 12:11:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 359DA8E0058 for ; Mon, 4 May 2020 12:11:17 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id DACFB181AC9B6 for ; Mon, 4 May 2020 16:11:16 +0000 (UTC) X-FDA: 76779526152.27.party30_62774a3c1d955 X-HE-Tag: party30_62774a3c1d955 X-Filterd-Recvd-Size: 3432 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Mon, 4 May 2020 16:11:16 +0000 (UTC) Received: by mail-wr1-f68.google.com with SMTP id i10so21624000wrv.10 for ; Mon, 04 May 2020 09:11:16 -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=Ikb1NUccpn+jAjApxYR6CGyOrt5Mz3G2NGEOLF74fNg=; b=N4boJknd+jWvrvOCeplce5SmXftpVNC82bRXMgGKXMq3lKyA+JFanroGuWSlwwfRek pyd76BHqGnLKmW/S8Vw88U+3pW/iIj5dApzneacrEWajyaZJdYiomS81B9va5zzxJSH8 8bYg0899d/8I6iQm2pvNP134V+l7SddVt4paM+T+hVFxOlE4j/Hv9AalWiMmQP3b8U6V +YlrxWxmOzVWkB+syOoDV2CmP9BQvZRT8b9dEf2qQnn2rsk3A7nltyOa20W7pysI0WKs CGd06YUmawyOgwlRpex5bL4zBtP6D9n+uEu0aVn1pv3Sv14xLJ0ID36680bwd8otCHfl VlsQ== X-Gm-Message-State: AGi0PubLSBhdnQ3I2Akmrn4/+Y0bRzBHsFNGD8X5g0Aot/HyjFXQmbTs vpJLy1yCZCQuK+KPMygFmGQ= X-Google-Smtp-Source: APiQypLGCfANnWZTQfVO9SCOnzdJmam+Y4cOod2gXphjbiTREAfybUuWJPsJo6FSZIMV1kR0/fYAOQ== X-Received: by 2002:a5d:4d05:: with SMTP id z5mr67890wrt.130.1588608675535; Mon, 04 May 2020 09:11:15 -0700 (PDT) Received: from localhost (ip-37-188-183-9.eurotel.cz. [37.188.183.9]) by smtp.gmail.com with ESMTPSA id n7sm13430505wmd.11.2020.05.04.09.11.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 May 2020 09:11:14 -0700 (PDT) Date: Mon, 4 May 2020 18:11:13 +0200 From: Michal Hocko To: Yafang Shao Cc: Andrew Morton , Shakeel Butt , Johannes Weiner , Roman Gushchin , Greg Thelen , Linux MM Subject: Re: [PATCH v2 2/2] mm, memcg: don't try to kill a process if memcg is not populated Message-ID: <20200504161113.GV22838@dhcp22.suse.cz> References: <20200504042621.10334-1-laoar.shao@gmail.com> <20200504042621.10334-3-laoar.shao@gmail.com> <20200504081848.GJ22838@dhcp22.suse.cz> <20200504124627.GP22838@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Bogosity: Ham, tests=bogofilter, spamicity=0.000012, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon 04-05-20 23:24:35, Yafang Shao wrote: > On Mon, May 4, 2020 at 8:46 PM Michal Hocko wrote: [...] > > But the oom situation and the oom report is simply something an admin > > has to expect especially when the hard limit is set to 0. With kmem > > accounting there is no guarantee that the target will be met. > > I'm always wondering that why not moving the kmem from this memcg to > the root_mem_cgroup in this situation ? > Then this memcg can be easily reclaimed. Roman was playing with kmem charges reparenting. But please note that this alone would be sufficient. Even LRU pages are not guaranteed to be reclaimable - think of the full swap space, memory might be pinned etc. -- Michal Hocko SUSE Labs