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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6CEE6C433EF for ; Tue, 5 Apr 2022 06:27:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BC1996B0071; Tue, 5 Apr 2022 02:27:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B71D66B0073; Tue, 5 Apr 2022 02:27:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A39536B0074; Tue, 5 Apr 2022 02:27:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 9083F6B0071 for ; Tue, 5 Apr 2022 02:27:12 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 591D820565 for ; Tue, 5 Apr 2022 06:27:02 +0000 (UTC) X-FDA: 79321842684.05.D68A39E Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf11.hostedemail.com (Postfix) with ESMTP id A75FC4001C for ; Tue, 5 Apr 2022 06:27:01 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 77CCD210DE; Tue, 5 Apr 2022 06:27:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1649140020; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Yh3Ex3Th+gF9Cqk/K++VhrpMY2seww3cQSgR3bJT/Hg=; b=Oi2QIer3acnB2qh/3gKgxeQvPSaRTPBE8h7WnJQCGkxdTcMy+Db8yjuRi5DAxorBEcAfCL hKdfWigOSnr9C7qSjjWpf9thxyS/fKtFkzS/LcxhoxwawIFl/VD3vOsV/1tqEkFfvUSjBQ BQNyPpSpioYZBU9cYrbtoMLG1w+zYrE= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 43B1BA3B89; Tue, 5 Apr 2022 06:27:00 +0000 (UTC) Date: Tue, 5 Apr 2022 08:26:59 +0200 From: Michal Hocko To: Wei Yang Cc: akpm@linux-foundation.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Roman Gushchin , Johannes Weiner Subject: Re: [PATCH] mm/memcg: non-hierarchical mode is deprecated Message-ID: References: <20220403020833.26164-1-richard.weiyang@gmail.com> <20220405022218.53idmvm2ha2tzmy2@master> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220405022218.53idmvm2ha2tzmy2@master> X-Rspam-User: X-Stat-Signature: pyajt5s9wzp38aakjfj93ynhou11pmg1 Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=Oi2QIer3; spf=pass (imf11.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: A75FC4001C X-HE-Tag: 1649140021-526827 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 Tue 05-04-22 02:22:18, Wei Yang wrote: > On Mon, Apr 04, 2022 at 11:27:53AM +0200, Michal Hocko wrote: > >On Sun 03-04-22 02:08:33, Wei Yang wrote: > >> After commit bef8620cd8e0 ("mm: memcg: deprecate the non-hierarchical > >> mode"), we won't have a NULL parent except root_mem_cgroup. And this > >> case is handled when (memcg == root). > >> > >> Signed-off-by: Wei Yang > >> CC: Roman Gushchin > >> CC: Johannes Weiner > > > >Acked-by: Michal Hocko > >Thanks! > > > > Thanks for the ack. When reading the code, I found one redundant check in > shrink_node_memcgs(). > > shrink_node_memcgs > mem_cgroup_below_min > mem_cgroup_supports_protection > mem_cgroup_below_low > mem_cgroup_supports_protection > > I am not sure it worthwhile to take it out. > > shrink_node_memcgs > mem_cgroup_supports_protection > mem_cgroup_below_min > mem_cgroup_below_low > > Look forward your opinion. I guess you refer to mem_cgroup_is_root check in mem_cgroup_supports_protection, right? You are right that the check is not really required because e{min,low} should always stay at 0 for the root memcg AFAICS. On the other hand the check is not in any hot path and it really adds clarity here because protection is not really supported on the root memcg. So I am not this is an overall win. -- Michal Hocko SUSE Labs