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 520E6C021BB for ; Wed, 26 Feb 2025 00:27:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DD1A96B008C; Tue, 25 Feb 2025 19:27:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D82526B0093; Tue, 25 Feb 2025 19:27:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C70016B0095; Tue, 25 Feb 2025 19:27:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id A88006B008C for ; Tue, 25 Feb 2025 19:27:36 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 2D49C51D35 for ; Wed, 26 Feb 2025 00:27:36 +0000 (UTC) X-FDA: 83160207312.12.D386510 Received: from gentwo.org (gentwo.org [62.72.0.81]) by imf05.hostedemail.com (Postfix) with ESMTP id 794C6100004 for ; Wed, 26 Feb 2025 00:27:34 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gentwo.org header.s=default header.b=cxXdZ6Xs; spf=pass (imf05.hostedemail.com: domain of cl@gentwo.org designates 62.72.0.81 as permitted sender) smtp.mailfrom=cl@gentwo.org; dmarc=pass (policy=reject) header.from=gentwo.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740529654; 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=g9FlV7pRnyG8DZM0VjS+mPc/f+w7KgXsrlZYVpVoacw=; b=mlD7P1xNyaWDfr3u906/QqTAXSpTSE1ZFETqhWfqRuZZC87NODfnGR6NiAu6KtlsP+ggmE k1kjyCiMcHV1y0cCuvQWJgWJK75q3xgzmn9PzbQ4HAELw+8gBtQIHqLH5pgNi0MoIlx5n2 WyJyC3iZjD9rMoSMXV2LHjSOksam2p4= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=gentwo.org header.s=default header.b=cxXdZ6Xs; spf=pass (imf05.hostedemail.com: domain of cl@gentwo.org designates 62.72.0.81 as permitted sender) smtp.mailfrom=cl@gentwo.org; dmarc=pass (policy=reject) header.from=gentwo.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740529654; a=rsa-sha256; cv=none; b=viJvzdaN08WZ1Q/laeTCwc58KH8txoiLfylYzztwiNg/1kJiV7+tZLsXSxW/0AIPWe8gfx SaMKxsuV5iSwruwLxIIw9N9oZHi8s2Z4e7Roo8PrSiI3GXox4oJJa/9nXwndVgy3jiDm4H rpT0geEdE1zEO5gzqFvzwcxNL+EboZI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gentwo.org; s=default; t=1740529061; bh=JqtvX/GAnigh8qhIsbXu+YjWzqwKsOTCbDk5t5lrV2A=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=cxXdZ6XsGMUvuy1BRqnCd5bkgbQ5oVDPQ4067KTsca5HXJxEcB+y4md31h5BFPmfS pZGYLKjmtdd6HMEKoVirHJPXsdjVTzE4ijOYAHktYywgzAQelGQI7BpE/bGBv9q8vV E+HynTbihMK4CG62CzdPRWgA9tRym+EHjTxMw4Nk= Received: by gentwo.org (Postfix, from userid 1003) id F418B4025D; Tue, 25 Feb 2025 16:17:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id F03CF4010D; Tue, 25 Feb 2025 16:17:40 -0800 (PST) Date: Tue, 25 Feb 2025 16:17:40 -0800 (PST) From: "Christoph Lameter (Ampere)" To: Vlastimil Babka cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, bpf , 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 In-Reply-To: <14422cf1-4a63-4115-87cb-92685e7dd91b@suse.cz> Message-ID: References: <14422cf1-4a63-4115-87cb-92685e7dd91b@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 794C6100004 X-Stat-Signature: sk3343tn1jriz1wbor96pw3scgknkjbz X-HE-Tag: 1740529654-342207 X-HE-Meta: U2FsdGVkX1/9KVx5o4Wj3VFEJ+imWCfjZhQGH3cy521fBJsZN7FC3XSBz/DtAu0lTqBLkZNn4OdmsTiQHfGTzrYOhyZvykct8UUkLNeHWuZxBUe+AfYXkrdRjG1UC3puh1W1NbJW7Np2A9O+CkM34R5wMCyAr9JqFQNVk5eiGYGFpaeMyNdoC+tG9Ek7skrBYaVqGhcyLRxoFWmdkLYpGjJrwnYuWOQc9tV4kKqsXhw3NQ3OB72YVDo7IqwR5vfxRk6DxuaFS/yFodU+2xbDRGsjjMHZSC9ZqXQTimlvdZ17vSMPcH9SFYRgv3BhMXfmr/ALKg/DQWRKBnq9h8fo/HzaY/FVYGuKZI3rfKV48nDZt6kFoKqHOsuZhx/8LqK9kZqnKi5pf24prov6VxqOCiFxVPky/Avf48X7vBMQbWS26HwqsmuIaec7yqTSYzHUGya6AQuR0sKIb5dR6ThW7jmr1lBL56u61FKxQtkN7eLm/RRvPIUfxwOhSIv0QIW2WgPec/Y5RcxlC7QRpxpaVq4rsT0/x5yBYOJqGhVE27G5GSKGn0Jw7sfD6xu8onYsef9bGshhluYiUWHBZ7qce3FATS2Ykro1PSyjLh+NHlA3mh/is1B0kMjHXEHelTI5Aaf0+K3jD3p+CatsURwVaOtVq2uXWkaY2Jje2ucskSj9hFHZV3XtvwkMnItsPvzCX53KjjVblFUJ/wdI/JMHW1+w4oXvrCHN8l0211YnRV+OQGl2usmWaSz+qPVY/D6vKZQOl0bq/7FtVppNRKj1Eomq7M1h4nQOhv6LtsNm8/bVFRK8705FxrcB+ZkOX2cXwGHaUvG5NO2FAIg3Qh+70Bqb2e13Gr9DkwcJmXBA5DQU+bZDRQXooc8IQbuOPRumqPjb0MfbZiK860yIbaoQJdhP1RZsbLJQRCHYu8WMbKomp2EPiAticSzcNk2z/yk/MwuC3Ittlf/8XEjBlUI X+xH9Ynf MHJM8XKa52JVMM90TXsnaxgFEkvu6mPyniH/+tjw9QqzNshJFreCaknNfbmYqmwGMEbunSUOpKNlYdOZLX72eVkh8c0tkRASnO2q0XZS5GBMBpVCnGRXUEoADVQEX62v5G4TRlj4jOB1h2CGavNWITnfF2hc/bX4tt37HpqXu7AwxnJh2jch9h8ApyOxQc0TwM97cytjwJ66B7ru1ratUvIyr+81wvy/h6Yo23pCJGb03aftX2+cfil86jPp4OorxGUdVoZX6l+rgelCsm4zH0rwUkn+ZF6gJw8vEWZ8MeI/hbjF5ilFeQN4ARtYNmJMbYDlQ 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: Let me just express my general concern. SLUB was written because SLAB became a Byzantine mess with layer upon layer of debugging and queues here and there and with "maintenance" for these queues going on every 2 seconds staggered on all processors. This caused a degree of OS noise that caused HPC jobs (and today we see similar issues with AI jobs) to not be able to accomplish a deterministic rendezvous. On some large machines we had ~10% of the whole memory vanish into one of the other queue on boot up with the customers being a bit upset were all the expensive memory went. It seems that were have nearly recreated the old nightmare again. I would suggest rewriting the whole allocator once again trying to simplify things as much as possible and isolating specialized allocator functionality needed for some subsystems into different APIs. The main allocation / free path needs to be as simple and as efficient as possible. It may not be possible to accomplish something like that given all the special casing that we have been pushing into it. Also consider the runtime security measures and verification stuff that is on by default at runtime as well.