Message ID | 20221121171202.22080-8-vbabka@suse.cz |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp1716948wrr; Mon, 21 Nov 2022 09:13:11 -0800 (PST) X-Google-Smtp-Source: AA0mqf4q6x0qxgZ2nBK7e3mlFokAoIlztFRqX/2ulklK2rcYNYZBpRVlzDBr1571i8kzVZQGMj1e X-Received: by 2002:a63:5f14:0:b0:43c:969f:18a7 with SMTP id t20-20020a635f14000000b0043c969f18a7mr18597356pgb.12.1669050790831; Mon, 21 Nov 2022 09:13:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669050790; cv=none; d=google.com; s=arc-20160816; b=ijkPBC/oshPOQReU8LhLGwDItLGGVsVVG69ncp/pBfgZsFvmHrWxxqVEvW/WIbTy17 7uy7uzbWGSCcqZDDfBVfGMHTLn18ln6CbAuD4Qdbs6tHq15MenJU+vSqMSFXND/czAf6 an9e1OVhoaUM9On3txF4RH8LWmA9qiSE5W3G9zpU7TljJ6JSXk7VQgCPrfTo4eevKyiU mRRBR9mDZ4tJogRRxtvqNIAO3e9RKzBzKvRVBJXjzEPDzbZD9bwT30I8obSQjlyqJE8p q5P4fLBZmynq+Yxpy0g28PAqjoeiOhN7C2mw8m2Ky4AxkVfIAiQV+nOUoHuZ7bjcM5NA aLzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature:dkim-signature; bh=i2JvvueNOyE9wh1FqFGLP1e7ObZGjB/Lqr6ycx9tY24=; b=Iv6lMn8Sg2WktUdwZac6IIOFPlt3uxMTeH5sNZVCLPBx0dZREqrrOf7I5DpeTCwBPm i9nOZU7rhn25DggTMC63hdCSDXxFNwAgotSIiYq5Pql6+dN1C15UQJ3bjGTI2cZ2G7Zi ac2z4iThAGGFP1LRgbjvqV8D48LviPYpyo6rRSf7wVvUybvkk+JQ+YWhRlqetj7n9rHM hplE92WXeyiWFr6KXcwXJUWNO4B7GxCUUYr1sAd4q9QD3oARD5E44gBNPmR4uwp5tdBO XeHmhWISyhNNG5v1xGy5JF48/RgICtpbcohau614cAIi1Jn1Ah4tJhcQf81BXkr/4VjH Uacg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=oObh6wdN; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=leDY5l4B; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c18-20020a056a00009200b0056cb8f67eefsi11009501pfj.70.2022.11.21.09.12.53; Mon, 21 Nov 2022 09:13:10 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=oObh6wdN; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=leDY5l4B; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231178AbiKURMc (ORCPT <rfc822;cjcooper78@gmail.com> + 99 others); Mon, 21 Nov 2022 12:12:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33150 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230442AbiKURMP (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 21 Nov 2022 12:12:15 -0500 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8432DCEFC6 for <linux-kernel@vger.kernel.org>; Mon, 21 Nov 2022 09:12:13 -0800 (PST) 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 D35E41F8B9; Mon, 21 Nov 2022 17:12:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1669050731; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=i2JvvueNOyE9wh1FqFGLP1e7ObZGjB/Lqr6ycx9tY24=; b=oObh6wdNyZY9Dk99j4ViHgNh4V3x7QkVPcXKRIc1vMg0NknSGlK4nStjQ3MC9q31fDkn3g VEXegpinTx+uvpuiTMD7CV+Q/YH333P46dlA7hmutWR0nA0aglK+xwBz3QqoiZ+jV+mG0P 0MNq2GbwWXP4QlFMuvb26vfpljrSZic= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1669050731; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=i2JvvueNOyE9wh1FqFGLP1e7ObZGjB/Lqr6ycx9tY24=; b=leDY5l4B4sBPGcsiGjIniDoS7JrKHJETEOsEfHQjeMxhOfosw5yHw4fzoQ38mjrhMZxumR q2GPwRTyterJdTDQ== 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 A6CDF13B03; Mon, 21 Nov 2022 17:12:11 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id SPMeKGuxe2MQeQAAMHmgww (envelope-from <vbabka@suse.cz>); Mon, 21 Nov 2022 17:12:11 +0000 From: Vlastimil Babka <vbabka@suse.cz> To: Christoph Lameter <cl@linux.com>, David Rientjes <rientjes@google.com>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, Pekka Enberg <penberg@kernel.org> Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>, Roman Gushchin <roman.gushchin@linux.dev>, Andrew Morton <akpm@linux-foundation.org>, Linus Torvalds <torvalds@linux-foundation.org>, Matthew Wilcox <willy@infradead.org>, patches@lists.linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Vlastimil Babka <vbabka@suse.cz> Subject: [PATCH 07/12] mm, slab: ignore SLAB_RECLAIM_ACCOUNT with CONFIG_SLUB_TINY Date: Mon, 21 Nov 2022 18:11:57 +0100 Message-Id: <20221121171202.22080-8-vbabka@suse.cz> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221121171202.22080-1-vbabka@suse.cz> References: <20221121171202.22080-1-vbabka@suse.cz> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750126601783094505?= X-GMAIL-MSGID: =?utf-8?q?1750126601783094505?= |
Series |
Introduce CONFIG_SLUB_TINY and deprecate SLOB
|
|
Commit Message
Vlastimil Babka
Nov. 21, 2022, 5:11 p.m. UTC
SLAB_RECLAIM_ACCOUNT caches allocate their slab pages with
__GFP_RECLAIMABLE and can help against fragmentation by grouping pages
by mobility, but on tiny systems mobility grouping is likely disabled
anyway and ignoring SLAB_RECLAIM_ACCOUNT might instead lead to merging
of caches that are made incompatible just by the flag.
Thus with CONFIG_SLUB_TINY, make SLAB_RECLAIM_ACCOUNT ineffective.
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
include/linux/slab.h | 4 ++++
1 file changed, 4 insertions(+)
Comments
On Mon, Nov 21, 2022 at 06:11:57PM +0100, Vlastimil Babka wrote: > SLAB_RECLAIM_ACCOUNT caches allocate their slab pages with > __GFP_RECLAIMABLE and can help against fragmentation by grouping pages > by mobility, but on tiny systems mobility grouping is likely disabled > anyway and ignoring SLAB_RECLAIM_ACCOUNT might instead lead to merging > of caches that are made incompatible just by the flag. > > Thus with CONFIG_SLUB_TINY, make SLAB_RECLAIM_ACCOUNT ineffective. Hm, do you see disabling all kernel memory accounting functionality with COFNIG_SLUB_TINY? I'd say yes. But in this case need to be consistent and disable it alltogether. Thanks!
On 11/24/22 02:20, Roman Gushchin wrote: > On Mon, Nov 21, 2022 at 06:11:57PM +0100, Vlastimil Babka wrote: >> SLAB_RECLAIM_ACCOUNT caches allocate their slab pages with >> __GFP_RECLAIMABLE and can help against fragmentation by grouping pages >> by mobility, but on tiny systems mobility grouping is likely disabled >> anyway and ignoring SLAB_RECLAIM_ACCOUNT might instead lead to merging >> of caches that are made incompatible just by the flag. >> >> Thus with CONFIG_SLUB_TINY, make SLAB_RECLAIM_ACCOUNT ineffective. > > Hm, do you see disabling all kernel memory accounting functionality > with COFNIG_SLUB_TINY? I'd say yes. But in this case need to be consistent > and disable it alltogether. SLAB_RECLAIM_ACCOUNT is kinda misnomer these days, as the only thing it does is to add __GFP_RECLAIMABLE to cache's gfp flags for the page allocator's mobility grouping. I guess the "ACCOUNT" part comes from being counted towards SReclaimable (vs SUnreclaim) in /proc/meminfo. So currently SLUB_TINY has no effect on MEMCG_KMEM (which you probably meant). Using those two together has little sense and had I stumbled while making this series upon a code that would become complicated, I would have made SLUB_TINY disable MEMCG_KMEM, but that didn't happen so I left as is for now. > Thanks!
On Thu, 24 Nov 2022, Vlastimil Babka wrote: > SLAB_RECLAIM_ACCOUNT is kinda misnomer these days, as the only thing it does > is to add __GFP_RECLAIMABLE to cache's gfp flags for the page allocator's > mobility grouping. I guess the "ACCOUNT" part comes from being counted > towards SReclaimable (vs SUnreclaim) in /proc/meminfo. Well these Sreclaimable etc counters visible in /proc/meminfo are used in the reclaim logic and are quite important there.
On 11/21/22 18:11, Vlastimil Babka wrote: > SLAB_RECLAIM_ACCOUNT caches allocate their slab pages with > __GFP_RECLAIMABLE and can help against fragmentation by grouping pages > by mobility, but on tiny systems mobility grouping is likely disabled > anyway and ignoring SLAB_RECLAIM_ACCOUNT might instead lead to merging > of caches that are made incompatible just by the flag. > > Thus with CONFIG_SLUB_TINY, make SLAB_RECLAIM_ACCOUNT ineffective. > > Signed-off-by: Vlastimil Babka <vbabka@suse.cz> > --- > include/linux/slab.h | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/include/linux/slab.h b/include/linux/slab.h > index 3ce9474c90ab..1cbbda03ad06 100644 > --- a/include/linux/slab.h > +++ b/include/linux/slab.h > @@ -129,7 +129,11 @@ > > /* The following flags affect the page allocator grouping pages by mobility */ > /* Objects are reclaimable */ > +#ifndef CONFIG_SLUB_TINY > #define SLAB_RECLAIM_ACCOUNT ((slab_flags_t __force)0x00020000U) > +#else > +#define SLAB_RECLAIM_ACCOUNT 0 Updating the last line above to: #define SLAB_RECLAIM_ACCOUNT ((slab_flags_t __force)0) In response to: https://lore.kernel.org/all/202211280441.yCEecX9z-lkp@intel.com/ Yeah it probably means that the other pre-existing flag variants that #define to 0 should be also adjusted to avoid these issues, but not as part of this series. > +#endif > #define SLAB_TEMPORARY SLAB_RECLAIM_ACCOUNT /* Objects are short-lived */ > > /*
diff --git a/include/linux/slab.h b/include/linux/slab.h index 3ce9474c90ab..1cbbda03ad06 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -129,7 +129,11 @@ /* The following flags affect the page allocator grouping pages by mobility */ /* Objects are reclaimable */ +#ifndef CONFIG_SLUB_TINY #define SLAB_RECLAIM_ACCOUNT ((slab_flags_t __force)0x00020000U) +#else +#define SLAB_RECLAIM_ACCOUNT 0 +#endif #define SLAB_TEMPORARY SLAB_RECLAIM_ACCOUNT /* Objects are short-lived */ /*