Message ID | 20240220-slab-cleanup-flags-v1-1-e657e373944a@suse.cz |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-73392-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2685:b0:108:e6aa:91d0 with SMTP id mn5csp533175dyc; Tue, 20 Feb 2024 08:59:39 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCVVpr2rAfGT5jkxBGnmB8bCYisBxUystDYfCy2QaioRK2+5LtOt8J6BPSJh/ep30JN80lRnc/jLSyTOSOhKBB1i5QlZaA== X-Google-Smtp-Source: AGHT+IEdoiLO0niDLeamCzhaAfCavi0870Z/IsZzwUBRZWKGfBItaYDJUrw5U7kdyuD45tBkwxZl X-Received: by 2002:ad4:4ee6:0:b0:68f:333d:a67d with SMTP id dv6-20020ad44ee6000000b0068f333da67dmr3715070qvb.19.1708448379679; Tue, 20 Feb 2024 08:59:39 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708448379; cv=pass; d=google.com; s=arc-20160816; b=PdnyPBP6XzFc+EE5Qrdw0/JgpJuRp6gxwCwYhXMBDfvhicUVGNfeHbuO81Z5XziiM4 g6Jf9Yd2AOs9kBbBoB88alNhbZeAbnZIVfuipzwUDPw0Tuy1Azd+RrmHDvmLwVF+GDO/ IZ+oh/E2oVf6/oZHM9yud8/qqytAjO258xc1HL28MxUJFjDr0Y/vK2eZfoga+g2m39Sg +0CYtUFb7XUtEqnc/Cbor6rZaDwDUsHM1PSedKn6ZsrjQcKydhfm9TztaoFfKgxX60Td HmXbfZBSM84ctxBU9DFIiAe0zCUZPw8eZc7h01jeFUIvPZK9FCI9ETgAdlLtX/iFQ+Ei plxQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :subject:date:from:dkim-signature:dkim-signature:dkim-signature :dkim-signature; bh=c4OC2yNSKLqgnXzwwPex64d+kZgeSX8gpLykWcl/SKw=; fh=H+kigXjdCOVpCxcHPaVg6SgkIx4KR669HTfmciEICLo=; b=lhj3rZKAg/2MhUt6b75CpQb+ZImY/6/M0+2vBx/I+1ODcjsdNIKefjn0qlPWGmQn2U eB2hXyeUgJW1ByeJ+6O7XOSd0apzwdf2CPT4FWLmkm44aUYIF+gN/ZuLzwz+tSEbwSNq +zwfXlyDo15t+WAVqmLXh1XYxctAt+Qib8JI7PHWUC2lisLjP3rkv2E6KcWt/xr+lKG1 y1ZX9do85llSJxL+4pz7zwNijmOOHG18lQmpfThJ9eAYUkpwdrP194JF1RTcuzqw6e5E cpE50kdUtlMveNLfsYwWaaVte1wX7f8+Qlt2bOA3egZOA1lxAFKfYtuTPqpxoCvx26Ub 9KbQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=RjcBobBc; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=RjcBobBc; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519; arc=pass (i=1 spf=pass spfdomain=suse.cz dkim=pass dkdomain=suse.cz dkim=pass dkdomain=suse.cz); spf=pass (google.com: domain of linux-kernel+bounces-73392-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-73392-ouuuleilei=gmail.com@vger.kernel.org" Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id d8-20020a05621421c800b0068f7e322364si3601128qvh.176.2024.02.20.08.59.39 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Feb 2024 08:59:39 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-73392-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=RjcBobBc; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=RjcBobBc; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519; arc=pass (i=1 spf=pass spfdomain=suse.cz dkim=pass dkdomain=suse.cz dkim=pass dkdomain=suse.cz); spf=pass (google.com: domain of linux-kernel+bounces-73392-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-73392-ouuuleilei=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 6BC081C22839 for <ouuuleilei@gmail.com>; Tue, 20 Feb 2024 16:59:39 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1E7FF77640; Tue, 20 Feb 2024 16:58:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b="RjcBobBc"; dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b="JwFYRXTq"; dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b="RjcBobBc"; dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b="JwFYRXTq" Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2C6CE76905 for <linux-kernel@vger.kernel.org>; Tue, 20 Feb 2024 16:58:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.135.223.130 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708448328; cv=none; b=V0CkvpTJfxIGYlXPcXfZUPb2k+i9yK8+6dEI+aypQml1ONSpJs8Cp/iIsb6/sRUvQ7BxCVB5rN+Iy42cZ6abJHGSjVDJEpHzahAHNL+bNnSYmVp+tIEBvdxNXM2IHqF/xG/bmRYhoyVzU3I12zprOH/bygGvf94YesvduAaYC5Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708448328; c=relaxed/simple; bh=OddJ5DHeDgks/i1mqhLaA/c2lRjGQhZqtVTweHMQxDw=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=qJbpJlIgHFDNm515cFcW/kWm0ypkoYUh9TkaN2hgeHoAXZFVSfG9fceUhJTUel+qjotWef7BE7ejxrFXc1HJllThfVKUkji3y5MvqcAwRg88xc3W++0o+trR5bn4RbLn9C0gYjshVamONZMGa/I5j4afKTLDHbdZjuXC5bPxMUI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz; spf=pass smtp.mailfrom=suse.cz; dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b=RjcBobBc; dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b=JwFYRXTq; dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b=RjcBobBc; dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b=JwFYRXTq; arc=none smtp.client-ip=195.135.223.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.cz Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 411FC21FBD; Tue, 20 Feb 2024 16:58:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1708448325; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=c4OC2yNSKLqgnXzwwPex64d+kZgeSX8gpLykWcl/SKw=; b=RjcBobBcQec/R6BNYj9LVtWzct1RqrXs1Hh50ZzAqswNqAlsoooklOUijnTxlI1nWX3Dco vuH3FfKT6Qa+8jU56MYk0OjiBEuJ4EPlTADsYBwQBRR3tlkxiEuAvZVOq++BoGa7z3lyWR aoDDvqQfuzptU51eGvOW8ET9m4xcNHo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1708448325; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=c4OC2yNSKLqgnXzwwPex64d+kZgeSX8gpLykWcl/SKw=; b=JwFYRXTqoVvqzk23AIOLXuMzXVHV47mrjeIz+Xwiw3CpIAK0JVphGsnYKwgXL6bz1pSKYM u8JpMqFaG3AeHuDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1708448325; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=c4OC2yNSKLqgnXzwwPex64d+kZgeSX8gpLykWcl/SKw=; b=RjcBobBcQec/R6BNYj9LVtWzct1RqrXs1Hh50ZzAqswNqAlsoooklOUijnTxlI1nWX3Dco vuH3FfKT6Qa+8jU56MYk0OjiBEuJ4EPlTADsYBwQBRR3tlkxiEuAvZVOq++BoGa7z3lyWR aoDDvqQfuzptU51eGvOW8ET9m4xcNHo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1708448325; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=c4OC2yNSKLqgnXzwwPex64d+kZgeSX8gpLykWcl/SKw=; b=JwFYRXTqoVvqzk23AIOLXuMzXVHV47mrjeIz+Xwiw3CpIAK0JVphGsnYKwgXL6bz1pSKYM u8JpMqFaG3AeHuDw== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 1915E13A93; Tue, 20 Feb 2024 16:58:45 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id GJHYBUXa1GVKXQAAD6G6ig (envelope-from <vbabka@suse.cz>); Tue, 20 Feb 2024 16:58:45 +0000 From: Vlastimil Babka <vbabka@suse.cz> Date: Tue, 20 Feb 2024 17:58:25 +0100 Subject: [PATCH 1/3] mm, slab: deprecate SLAB_MEM_SPREAD flag Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20240220-slab-cleanup-flags-v1-1-e657e373944a@suse.cz> References: <20240220-slab-cleanup-flags-v1-0-e657e373944a@suse.cz> In-Reply-To: <20240220-slab-cleanup-flags-v1-0-e657e373944a@suse.cz> To: Christoph Lameter <cl@linux.com>, Pekka Enberg <penberg@kernel.org>, David Rientjes <rientjes@google.com>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, Andrew Morton <akpm@linux-foundation.org>, Roman Gushchin <roman.gushchin@linux.dev>, Hyeonggon Yoo <42.hyeyoo@gmail.com>, Andrey Ryabinin <ryabinin.a.a@gmail.com>, Alexander Potapenko <glider@google.com>, Andrey Konovalov <andreyknvl@gmail.com>, Dmitry Vyukov <dvyukov@google.com>, Vincenzo Frascino <vincenzo.frascino@arm.com> Cc: Zheng Yejian <zhengyejian1@huawei.com>, Xiongwei Song <xiongwei.song@windriver.com>, Chengming Zhou <chengming.zhou@linux.dev>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, Vlastimil Babka <vbabka@suse.cz>, Steven Rostedt <rostedt@goodmis.org> X-Mailer: b4 0.13.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1731; i=vbabka@suse.cz; h=from:subject:message-id; bh=OddJ5DHeDgks/i1mqhLaA/c2lRjGQhZqtVTweHMQxDw=; b=owEBbQGS/pANAwAIAbvgsHXSRYiaAcsmYgBl1No9wmY1D3tW/Cy64eGuViYQaGuyi/p0I9ZML 1aOynVc32uJATMEAAEIAB0WIQR7u8hBFZkjSJZITfG74LB10kWImgUCZdTaPQAKCRC74LB10kWI mgcCB/9ah3oEc1eVnw/8rJfS4V2CrkLLtkwjbxIk0QO1Y0hJK6fdAYScMioTiqBbFz2fYneiEib unIEdHVvpl+axQ6ErHTm8ti5I3TyU4MWWs83wr4c2KDwr6M1dl/PvpBvMynOrlEipojbhKdzBUG M7r0KCDPswYFY/bWZNDMSglmuV4rdwkzWpAlBnmUSK1ARpf/CL/dLuc8EoPraztYVvBTuVl7/sS yeaXUhG1SHr+j+ewEl+8Ng27ejIu7HOiappS80WyxN0awRxddapuB+uGZB7Oe88F1qMmz88+5/T Zwh17MejM5IUm/PPb+QCsLgpmJBon11M/C4qFpCzuDCoY2ct X-Developer-Key: i=vbabka@suse.cz; a=openpgp; fpr=A940D434992C2E8E99103D50224FA7E7CC82A664 Authentication-Results: smtp-out1.suse.de; none X-Spam-Level: X-Spam-Score: -3.81 X-Spamd-Result: default: False [-3.81 / 50.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; REPLY(-4.00)[]; BAYES_HAM(-0.01)[46.40%]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_RATELIMIT(0.00)[to_ip_from(RLqdadssyy1w6u3twx3pq4jyny)]; RCVD_COUNT_THREE(0.00)[3]; DKIM_SIGNED(0.00)[suse.cz:s=susede2_rsa,suse.cz:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-1.000]; RCPT_COUNT_TWELVE(0.00)[20]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.cz:email]; FREEMAIL_TO(0.00)[linux.com,kernel.org,google.com,lge.com,linux-foundation.org,linux.dev,gmail.com,arm.com]; FUZZY_BLOCKED(0.00)[rspamd.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; SUSPICIOUS_RECIPS(1.50)[] X-Spam-Flag: NO X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791437968119590710 X-GMAIL-MSGID: 1791437968119590710 |
Series |
cleanup of SLAB_ flags
|
|
Commit Message
Vlastimil Babka
Feb. 20, 2024, 4:58 p.m. UTC
The SLAB_MEM_SPREAD flag used to be implemented in SLAB, which was
removed. SLUB instead relies on the page allocator's NUMA policies.
Change the flag's value to 0 to free up the value it had, and mark it
for full removal once all users are gone.
Reported-by: Steven Rostedt <rostedt@goodmis.org>
Closes: https://lore.kernel.org/all/20240131172027.10f64405@gandalf.local.home/
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
include/linux/slab.h | 5 +++--
mm/slab.h | 1 -
2 files changed, 3 insertions(+), 3 deletions(-)
Comments
> The SLAB_MEM_SPREAD flag used to be implemented in SLAB, which was > removed. SLUB instead relies on the page allocator's NUMA policies. > Change the flag's value to 0 to free up the value it had, and mark it > for full removal once all users are gone. > > Reported-by: Steven Rostedt <rostedt@goodmis.org> > Closes: https://lore.kernel.org/all/20240131172027.10f64405@gandalf.local.home/ > Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Ran a rough test with build and bootup, feel free to add Tested-by: Xiongwei Song <xiongwei.song@windriver.com> Reviewed-by: Xiongwei Song <xiongwei.song@windriver.com> > --- > include/linux/slab.h | 5 +++-- > mm/slab.h | 1 - > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/include/linux/slab.h b/include/linux/slab.h > index b5f5ee8308d0..6252f44115c2 100644 > --- a/include/linux/slab.h > +++ b/include/linux/slab.h > @@ -96,8 +96,6 @@ > */ > /* Defer freeing slabs to RCU */ > #define SLAB_TYPESAFE_BY_RCU ((slab_flags_t __force)0x00080000U) > -/* Spread some memory over cpuset */ > -#define SLAB_MEM_SPREAD ((slab_flags_t __force)0x00100000U) > /* Trace allocations and frees */ > #define SLAB_TRACE ((slab_flags_t __force)0x00200000U) > > @@ -164,6 +162,9 @@ > #endif > #define SLAB_TEMPORARY SLAB_RECLAIM_ACCOUNT /* Objects are short-lived */ > > +/* Obsolete unused flag, to be removed */ > +#define SLAB_MEM_SPREAD 0 > + > /* > * ZERO_SIZE_PTR will be returned for zero sized kmalloc requests. > * > diff --git a/mm/slab.h b/mm/slab.h > index 54deeb0428c6..f4534eefb35d 100644 > --- a/mm/slab.h > +++ b/mm/slab.h > @@ -469,7 +469,6 @@ static inline bool is_kmalloc_cache(struct kmem_cache *s) > SLAB_STORE_USER | \ > SLAB_TRACE | \ > SLAB_CONSISTENCY_CHECKS | \ > - SLAB_MEM_SPREAD | \ > SLAB_NOLEAKTRACE | \ > SLAB_RECLAIM_ACCOUNT | \ > SLAB_TEMPORARY | \ > > -- > 2.43.1
On 2024/2/21 00:58, Vlastimil Babka wrote: > The SLAB_MEM_SPREAD flag used to be implemented in SLAB, which was > removed. SLUB instead relies on the page allocator's NUMA policies. > Change the flag's value to 0 to free up the value it had, and mark it > for full removal once all users are gone. > > Reported-by: Steven Rostedt <rostedt@goodmis.org> > Closes: https://lore.kernel.org/all/20240131172027.10f64405@gandalf.local.home/ > Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Reviewed-by: Chengming Zhou <chengming.zhou@linux.dev> Thanks! > --- > include/linux/slab.h | 5 +++-- > mm/slab.h | 1 - > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/include/linux/slab.h b/include/linux/slab.h > index b5f5ee8308d0..6252f44115c2 100644 > --- a/include/linux/slab.h > +++ b/include/linux/slab.h > @@ -96,8 +96,6 @@ > */ > /* Defer freeing slabs to RCU */ > #define SLAB_TYPESAFE_BY_RCU ((slab_flags_t __force)0x00080000U) > -/* Spread some memory over cpuset */ > -#define SLAB_MEM_SPREAD ((slab_flags_t __force)0x00100000U) > /* Trace allocations and frees */ > #define SLAB_TRACE ((slab_flags_t __force)0x00200000U) > > @@ -164,6 +162,9 @@ > #endif > #define SLAB_TEMPORARY SLAB_RECLAIM_ACCOUNT /* Objects are short-lived */ > > +/* Obsolete unused flag, to be removed */ > +#define SLAB_MEM_SPREAD 0 > + > /* > * ZERO_SIZE_PTR will be returned for zero sized kmalloc requests. > * > diff --git a/mm/slab.h b/mm/slab.h > index 54deeb0428c6..f4534eefb35d 100644 > --- a/mm/slab.h > +++ b/mm/slab.h > @@ -469,7 +469,6 @@ static inline bool is_kmalloc_cache(struct kmem_cache *s) > SLAB_STORE_USER | \ > SLAB_TRACE | \ > SLAB_CONSISTENCY_CHECKS | \ > - SLAB_MEM_SPREAD | \ > SLAB_NOLEAKTRACE | \ > SLAB_RECLAIM_ACCOUNT | \ > SLAB_TEMPORARY | \ >
On Tue, Feb 20, 2024 at 05:58:25PM +0100, Vlastimil Babka wrote: 0;95;0c> The SLAB_MEM_SPREAD flag used to be implemented in SLAB, which was > removed. SLUB instead relies on the page allocator's NUMA policies. > Change the flag's value to 0 to free up the value it had, and mark it > for full removal once all users are gone. > > Reported-by: Steven Rostedt <rostedt@goodmis.org> > Closes: https://lore.kernel.org/all/20240131172027.10f64405@gandalf.local.home/ > Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Reviewed-by: Roman Gushchin <roman.gushchin@linux.dev> Do you plan to follow up with a patch series removing all usages? Thanks!
Hi Vlastimil, > On Tue, Feb 20, 2024 at 05:58:25PM +0100, Vlastimil Babka wrote: > 0;95;0c> The SLAB_MEM_SPREAD flag used to be implemented in SLAB, which was > > removed. SLUB instead relies on the page allocator's NUMA policies. > > Change the flag's value to 0 to free up the value it had, and mark it > > for full removal once all users are gone. > > > > Reported-by: Steven Rostedt <rostedt@goodmis.org> > > Closes: https://lore.kernel.org/all/20240131172027.10f64405@gandalf.local.home/ > > Signed-off-by: Vlastimil Babka <vbabka@suse.cz> > > Reviewed-by: Roman Gushchin <roman.gushchin@linux.dev> > > Do you plan to follow up with a patch series removing all usages? If you are not available with it, I can do. Regards, Xiongwei
On 2024/2/22 09:10, Song, Xiongwei wrote: > Hi Vlastimil, > >> On Tue, Feb 20, 2024 at 05:58:25PM +0100, Vlastimil Babka wrote: >> 0;95;0c> The SLAB_MEM_SPREAD flag used to be implemented in SLAB, which was >>> removed. SLUB instead relies on the page allocator's NUMA policies. >>> Change the flag's value to 0 to free up the value it had, and mark it >>> for full removal once all users are gone. >>> >>> Reported-by: Steven Rostedt <rostedt@goodmis.org> >>> Closes: https://lore.kernel.org/all/20240131172027.10f64405@gandalf.local.home/ >>> Signed-off-by: Vlastimil Babka <vbabka@suse.cz> >> >> Reviewed-by: Roman Gushchin <roman.gushchin@linux.dev> >> >> Do you plan to follow up with a patch series removing all usages? > > If you are not available with it, I can do. Actually, I have done it yesterday. Sorry, I just forgot this task. :) I plan to send out it after this series merged in the slab branch. And I'm wondering is it better to put all diffs in one huge patch or split every diff to each patch? Thanks!
> On 2024/2/22 09:10, Song, Xiongwei wrote: > > Hi Vlastimil, > > > >> On Tue, Feb 20, 2024 at 05:58:25PM +0100, Vlastimil Babka wrote: > >> 0;95;0c> The SLAB_MEM_SPREAD flag used to be implemented in SLAB, which was > >>> removed. SLUB instead relies on the page allocator's NUMA policies. > >>> Change the flag's value to 0 to free up the value it had, and mark it > >>> for full removal once all users are gone. > >>> > >>> Reported-by: Steven Rostedt <rostedt@goodmis.org> > >>> Closes: https://lore.kernel.org/all/20240131172027.10f64405@gandalf.local.home/ > >>> Signed-off-by: Vlastimil Babka <vbabka@suse.cz> > >> > >> Reviewed-by: Roman Gushchin <roman.gushchin@linux.dev> > >> > >> Do you plan to follow up with a patch series removing all usages? > > > > If you are not available with it, I can do. > > Actually, I have done it yesterday. Sorry, I just forgot this task. :) Ok, that's fine. I remember you said you wanted to do it. But it's been for a long time. I thinks that's why Vlastimil sent the series out. You could've said what you've done or your any update when you reviewed this series yesterday, which wouldn't make others confused. So keeping update would be better. Thanks. > > I plan to send out it after this series merged in the slab branch. And > I'm wondering is it better to put all diffs in one huge patch or split > every diff to each patch? > > Thanks!
On 2/22/24 03:32, Chengming Zhou wrote: > On 2024/2/22 09:10, Song, Xiongwei wrote: >> Hi Vlastimil, >> >>> On Tue, Feb 20, 2024 at 05:58:25PM +0100, Vlastimil Babka wrote: >>> 0;95;0c> The SLAB_MEM_SPREAD flag used to be implemented in SLAB, which was >>>> removed. SLUB instead relies on the page allocator's NUMA policies. >>>> Change the flag's value to 0 to free up the value it had, and mark it >>>> for full removal once all users are gone. >>>> >>>> Reported-by: Steven Rostedt <rostedt@goodmis.org> >>>> Closes: https://lore.kernel.org/all/20240131172027.10f64405@gandalf.local.home/ >>>> Signed-off-by: Vlastimil Babka <vbabka@suse.cz> >>> >>> Reviewed-by: Roman Gushchin <roman.gushchin@linux.dev> >>> >>> Do you plan to follow up with a patch series removing all usages? >> >> If you are not available with it, I can do. > > Actually, I have done it yesterday. Sorry, I just forgot this task. :) > > I plan to send out it after this series merged in the slab branch. And > I'm wondering is it better to put all diffs in one huge patch or split > every diff to each patch? I'd suggest you do a patch per subsystem (mostly different filesystems) and send them out to respective maintainers to pick in their trees. I've talked to David from btrfs and he suggested this way. You don't need to wait for this series to be merged. The flag is already a no-op as of 6.8-rc1. Also I'd suggest sending the patches individually. In a series they wouldn't depend on each other anyway, and you would either have to Cc maintainers separately per patch of the series, or everyone on everything, and there would always be somebody who would prefer the other way that you pick. > Thanks!
On 2024/2/24 00:41, Vlastimil Babka wrote: > On 2/22/24 03:32, Chengming Zhou wrote: >> On 2024/2/22 09:10, Song, Xiongwei wrote: >>> Hi Vlastimil, >>> >>>> On Tue, Feb 20, 2024 at 05:58:25PM +0100, Vlastimil Babka wrote: >>>> 0;95;0c> The SLAB_MEM_SPREAD flag used to be implemented in SLAB, which was >>>>> removed. SLUB instead relies on the page allocator's NUMA policies. >>>>> Change the flag's value to 0 to free up the value it had, and mark it >>>>> for full removal once all users are gone. >>>>> >>>>> Reported-by: Steven Rostedt <rostedt@goodmis.org> >>>>> Closes: https://lore.kernel.org/all/20240131172027.10f64405@gandalf.local.home/ >>>>> Signed-off-by: Vlastimil Babka <vbabka@suse.cz> >>>> >>>> Reviewed-by: Roman Gushchin <roman.gushchin@linux.dev> >>>> >>>> Do you plan to follow up with a patch series removing all usages? >>> >>> If you are not available with it, I can do. >> >> Actually, I have done it yesterday. Sorry, I just forgot this task. :) >> >> I plan to send out it after this series merged in the slab branch. And >> I'm wondering is it better to put all diffs in one huge patch or split >> every diff to each patch? > > I'd suggest you do a patch per subsystem (mostly different filesystems) and > send them out to respective maintainers to pick in their trees. I've talked > to David from btrfs and he suggested this way. Ok, will send out individually. > > You don't need to wait for this series to be merged. The flag is already a > no-op as of 6.8-rc1. Also I'd suggest sending the patches individually. In a > series they wouldn't depend on each other anyway, and you would either have > to Cc maintainers separately per patch of the series, or everyone on > everything, and there would always be somebody who would prefer the other > way that you pick. Right, thanks for your instructions! > >> Thanks! >
diff --git a/include/linux/slab.h b/include/linux/slab.h index b5f5ee8308d0..6252f44115c2 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -96,8 +96,6 @@ */ /* Defer freeing slabs to RCU */ #define SLAB_TYPESAFE_BY_RCU ((slab_flags_t __force)0x00080000U) -/* Spread some memory over cpuset */ -#define SLAB_MEM_SPREAD ((slab_flags_t __force)0x00100000U) /* Trace allocations and frees */ #define SLAB_TRACE ((slab_flags_t __force)0x00200000U) @@ -164,6 +162,9 @@ #endif #define SLAB_TEMPORARY SLAB_RECLAIM_ACCOUNT /* Objects are short-lived */ +/* Obsolete unused flag, to be removed */ +#define SLAB_MEM_SPREAD 0 + /* * ZERO_SIZE_PTR will be returned for zero sized kmalloc requests. * diff --git a/mm/slab.h b/mm/slab.h index 54deeb0428c6..f4534eefb35d 100644 --- a/mm/slab.h +++ b/mm/slab.h @@ -469,7 +469,6 @@ static inline bool is_kmalloc_cache(struct kmem_cache *s) SLAB_STORE_USER | \ SLAB_TRACE | \ SLAB_CONSISTENCY_CHECKS | \ - SLAB_MEM_SPREAD | \ SLAB_NOLEAKTRACE | \ SLAB_RECLAIM_ACCOUNT | \ SLAB_TEMPORARY | \