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 B6353ECAAD1 for ; Tue, 30 Aug 2022 06:45:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2A4146B0073; Tue, 30 Aug 2022 02:45:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2058A940007; Tue, 30 Aug 2022 02:45:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 07EA26B0075; Tue, 30 Aug 2022 02:45:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E6D8A6B0073 for ; Tue, 30 Aug 2022 02:45:00 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B89F0C0E92 for ; Tue, 30 Aug 2022 06:45:00 +0000 (UTC) X-FDA: 79855321560.28.851BB34 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf09.hostedemail.com (Postfix) with ESMTP id 4D38214000D for ; Tue, 30 Aug 2022 06:44:59 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id EEE1E1F991; Tue, 30 Aug 2022 06:44:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1661841897; 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=aqwnetj8xbUKp5QppMH6N1q9Y/Y7o7+y1Plx+97UHPo=; b=HdWK9N8YSyfzISyC1zORz7jOWzLnPpeT8qKNYhP08SyMyCS/7i/QILKBq6O1dwotIJOHl2 mI34yRsJHN4QT79t3hxHFsnK35Vtajheuv5CeJ/t4XhboAuFlz4WBBiaSUfpDyJvRuZPhN /mlH4FOLyd5WRp/ArheHZ/Gk6E1XNmE= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id CDB7813ACF; Tue, 30 Aug 2022 06:44:57 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id ofHiL+mxDWObJAAAMHmgww (envelope-from ); Tue, 30 Aug 2022 06:44:57 +0000 Date: Tue, 30 Aug 2022 08:44:57 +0200 From: Michal Hocko To: Kairui Song Cc: cgroups@vger.kernel.org, linux-mm@kvack.org, Johannes Weiner , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] mm: memcontrol: remove mem_cgroup_kmem_disabled Message-ID: References: <20220830055949.12640-1-ryncsn@gmail.com> <20220830055949.12640-2-ryncsn@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220830055949.12640-2-ryncsn@gmail.com> ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=HdWK9N8Y; spf=pass (imf09.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661841899; a=rsa-sha256; cv=none; b=Q9KmqwjY3Bq2v/mhMoAMMkzxUA6jR7gXPh6orQuXA6mcXHvYDLP+dZP978m0jKv+h2tuLo NdK59ncpPfKJC2W2VH5rCmKlx4Cu8OlFWNQGEDkvFlIrT+8M20H9m9eaKonW+Em/wZDzzz WSjf8nfr2rkZ+pZ8jhfd1mHBW775Y8E= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661841899; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=aqwnetj8xbUKp5QppMH6N1q9Y/Y7o7+y1Plx+97UHPo=; b=nbBX504Pi8rLOzS66i6W8L1RP4gdcEOtG02HEibMCPpZt1vConhe7Ezdo0CLujEYVYjloV nxhDrbZfdKY/Z7yG425f4iQnByYcFhGtLhvP19puFxbp0Djgc9WODJeq1SpI4AuilnBrD1 M+7N/k7gHGvVH9UC1mTQQBHO1qg2w1I= X-Rspamd-Queue-Id: 4D38214000D X-Rspam-User: Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=HdWK9N8Y; spf=pass (imf09.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspamd-Server: rspam02 X-Stat-Signature: g4to859tg5o9rwd7jxbqwot4roqtqswk X-HE-Tag: 1661841899-623371 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 30-08-22 13:59:48, Kairui Song wrote: > From: Kairui Song > > There are currently two helpers for checking if cgroup kmem > accounting is enabled: > > - mem_cgroup_kmem_disabled > - memcg_kmem_enabled Yes, this is a bit confusing indeed! > mem_cgroup_kmem_disabled is a simple helper that returns true if > cgroup.memory=nokmem is specified, otherwise returns false. > > memcg_kmem_enabled is a bit different, it returns true if > cgroup.memory=nokmem is not specified and there is at least one > non-root cgroup ever created. And once there is any non-root memcg > created, it won't go back to return false again. > > This may help improve performance for some corner use cases where > the user enables memory cgroup and kmem accounting globally but never > create any cgroup. > > Considering that corner case is rare, especially nowadays cgroup is > widely used as a standard way to organize services. Is it really that rare? Most configurations would use a default setup, so both MEMCG enabled and without nokmem on cmd line yet the memory controller is not enabled in their setups. > And the "once > enabled never disable" behavior is kind of strange. This commit simplifies > the behavior of memcg_kmem_enabled, making it simply the opposite of > mem_cgroup_kmem_disabled, always true if cgroup.memory=nokmem is > not specified. So mem_cgroup_kmem_disabled can be dropped. > > This simplifies the code, and besides, memcg_kmem_enabled makes use > of static key so it has a lower overhead. I agree that this is slightly confusing and undocumented. The first step would be finding out why we need both outside of the memcg proper. E.g. it doesn't make much sense to me that count_objcg_event uses the command line variant when it should be using the dynamic (and more optimized no branch) variant. On the other hand pcpu_alloc_chunk seems to be different because it can be called before the controller is enabled but maybe we do not need to waste memory before that? Similarly new_kmalloc_cache. I suspect these are mostly to simplify the code and reduce special casing. > > Signed-off-by: Kairui Song > --- > include/linux/memcontrol.h | 8 +------- > mm/memcontrol.c | 17 +++++++---------- > mm/percpu.c | 2 +- > mm/slab_common.c | 2 +- > 4 files changed, 10 insertions(+), 19 deletions(-) I do not think that saving 9 LOC and sacrifice optimization that might be useful is a good justification. -- Michal Hocko SUSE Labs