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 92829C021A4 for ; Mon, 24 Feb 2025 18:02:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0E4D128000D; Mon, 24 Feb 2025 13:02:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 094E228000C; Mon, 24 Feb 2025 13:02:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E9E3528000D; Mon, 24 Feb 2025 13:02:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id BFB0628000C for ; Mon, 24 Feb 2025 13:02:27 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 3F9341A1A20 for ; Mon, 24 Feb 2025 18:02:27 +0000 (UTC) X-FDA: 83155607934.02.ED7A62D Received: from out-172.mta1.migadu.com (out-172.mta1.migadu.com [95.215.58.172]) by imf23.hostedemail.com (Postfix) with ESMTP id 88314140004 for ; Mon, 24 Feb 2025 18:02:20 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=fREhkmz8; spf=pass (imf23.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.172 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740420140; 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=7pUi0j0NH+2Nm8G2EyjCJc5I0bdo9iNSE1fivswXWbI=; b=f6LHoQNPJ70GTVFGx6GKN0gveMEApC291s5CqpEv0waGZLdTZ+S9SovnvPjkGGUP3F0d6P 7oKVoSNX8vQPMwQbEDKQzKC6JOa3mWL1WPWljeS19t9Jih/SxhHh7dRRJSHSsGNQ7sSria ir3Jfd4c8WRvrkoLu6U78WedMMmkrMQ= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=fREhkmz8; spf=pass (imf23.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.172 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740420140; a=rsa-sha256; cv=none; b=2H6EF38ECLfTeX7dqa2nwH2Rf3qaoMFruVmz2eBhoAz0PdLZppGuzoP//dLszkzRMzeWTo 54OIT9i57S+yI9m56s3jtPcxsuoJU7frPBlqExLF9Te2P87fS6mxIgpwBBB+UdUJDB2WPC Kx/c9fgFgriOakoF0pA6Tq5ZUCfiPos= Date: Mon, 24 Feb 2025 10:02:09 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1740420136; h=from:from:reply-to:subject:subject: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=7pUi0j0NH+2Nm8G2EyjCJc5I0bdo9iNSE1fivswXWbI=; b=fREhkmz8N7UuFk2SdutLbx1ycQZ4cG5VsR3I/Hd2Cvb2GFpvGaN1apfZez+2/G6QNmP/41 M3cVSBBu0cynKsmbaXw/sJXNy9dsrPChQrMBR8bUUt8+7Fff+chF9eqKKqUwEozCM3Zd7j yl40olKVf+zuW0c365UkhHnmkdj7sos= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Vlastimil Babka Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, bpf , Christoph Lameter , David Rientjes , Hyeonggon Yoo <42.hyeyoo@gmail.com>, "Uladzislau Rezki (Sony)" , Alexei Starovoitov Subject: Re: [LSF/MM/BPF TOPIC] SLUB allocator, mainly the sheaves caching layer Message-ID: References: <14422cf1-4a63-4115-87cb-92685e7dd91b@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14422cf1-4a63-4115-87cb-92685e7dd91b@suse.cz> X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 88314140004 X-Stat-Signature: a61aukg3qoy79iqwoyctipwhorgtxrtd X-Rspam-User: X-HE-Tag: 1740420140-519001 X-HE-Meta: U2FsdGVkX1+A0W2k0+gyQgwmeuTjXrdBmwEnJUAzTSJlm+V6S3p16GDHOc1OpFOisZnL/+d0dlKxdowHx06WzvFDf2ZXo/KPQocML1X9MKJM1/fBMOWTdNivmeirl0DRCOB9vj9Nz27QMghhCMOkQZDYEhK/M5pKkLz/1+Nh7aw/q95hb/nVWAbkLkHwIAUwMTCeRB3B/7OiJeQ4gHqyCU8bhz5Iml2E2kPVkoXz0YRbrxpMm6QPweAqYg3zKcMOEg8K8idyVTH0JYXv5bI3hFJI0+1OrtS78S8x+qYAYKUne4srQKIVQVI4t7ImC5DOxBGh8tb5Z0xEsXdI2s7qO3PkfMB1/xXqZywhKxKAWTZC1hA8+VEX+YNfLeoR8vm/lFpOPCaon5+n2fe/sNxbaT+Kmd2hYsM3XDMsVkSyECiKCR9Hb6nYpGpMHiIVxeksVUVbI7xfYu7qQ3V9YeC5/5G/ArDvTqT4XtUw3Cmmsm393sPS82Q6zgLKYtMDUOR2L4opK/53TR/hBY8cyJO2MQfR4iAwSrMbJ44NhEI4+pQWWpuV6fVsB2Yz1I6AXIez2KYfmsQYctHjdbuTX2HE5B5Ytp1VTSgLELl79PWUs8RiKsKY6ktooMk4UG7NVe7Z9IwmKGlUVB1LYWyj+reqY6bt68ApzPy1h5O7iRqB2Y/9HfGoFsl41U6RRyEqobWxQZHU65rxo5v8k8nsrU+3O8GX5x7ALsBbHJWhkHLJBa9MFKyw16m2SKeNgW+cOFzWGq5NelG2uVNwbKD5c22JRFE3gxqylHqkfjMZMi01ja8mq+J0nbgMT6akA3KaEODlJjNedY+A1lk+50h9ho1ctBQGGkqeJWQMH5KmUcJIWPnhnubgA2T9+cAAb5GcjqjP+UUUN7EjYdjc9XnlZtTafyyJJ2lVEmNTGieP0GbUCpp08AAf6xXMTzlC+Gkg5HtZE3ocA/oV3B2BezvKKBF nGfb3NJI dbpCzMqtXULA9S5t5e9CU+BE6o/DTf8JJ2T0q/gTH06EeKtcI2f8IftMZSkyipYbd4vUXVZtdI7FMfADY3H3+oklAxKAP7ieKqjowv18gPc4J7eDyDdoObQoaxVFBmh0t2bGSJA+nC1CobK4BO0f4ixPaJiHXMfQBozwtoIenGbVzHM97dtZvZhwEXwLnMshYZiM2HGkbm8m/2bDI4CKJXrZd9FNIRml4jNROPuHwe+PwEQbor5yo4N8zMERpGotH9Wsj 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: List-Subscribe: List-Unsubscribe: On Mon, Feb 24, 2025 at 05:13:25PM +0100, Vlastimil Babka wrote: > Hi, > > I'd like to propose a session about the SLUB allocator. > > Mainly I would like to discuss the addition of the sheaves caching layer, > the latest RFC posted at [1]. > > The goals of that work is to: > > - Reduce fastpath overhead. The current freeing fastpath only can be used if > the same target slab is still the cpu slab, which can be only expected for a > very short term allocations. Further improvements should come from the new > local_trylock_t primitive. > > - Improve efficiency of users such as like maple tree, thanks to more > efficient preallocations, and kfree_rcu batching/reusal > > - Hopefully also facilitate further changes needed for bpf allocations, also > via local_trylock_t, that could possibly extend to the other parts of the > implementation as needed. > > The controversial discussion points I expect about this approach are: > > - Either sheaves will not support NUMA restrictions (as in current RFC), or > bring back the alien cache flushing issues of SLAB (or there's a better idea?) > > - Will it be possible to eventually have sheaves enabled for every cache and > replace the current slub's fastpaths with it? Arguably these are also not > very efficient when NUMA-restricted allocations are requested for varying > NUMA nodes (cpu slab is flushed if it's from a wrong node, to load a slab > from the requested node). > > Besides sheaves, I'd like to summarize recent kfree_rcu() changes and we > could discuss further improvements to that. > > Also we can discuss what's needed to support bpf allocations. I've talked > about it last year, but then focused on other things, so Alexei has been > driving that recently (so far in the page allocator). What about pre-memcg-charged sheaves? We had to disable memcg charging of some kernel allocations and I think sheaves can help in reenabling it.