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 B7557C7618D for ; Thu, 16 Mar 2023 08:18:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 155A1900003; Thu, 16 Mar 2023 04:18:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 105C2900002; Thu, 16 Mar 2023 04:18:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F0F34900003; Thu, 16 Mar 2023 04:18:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id DC638900002 for ; Thu, 16 Mar 2023 04:18:15 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 9DB63804D2 for ; Thu, 16 Mar 2023 08:18:15 +0000 (UTC) X-FDA: 80574058950.21.B78D598 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf04.hostedemail.com (Postfix) with ESMTP id 2FACD40002 for ; Thu, 16 Mar 2023 08:18:12 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=CEKvMlo8; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="6KYYDi/9"; spf=pass (imf04.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678954693; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=hatJpOnSsIAYycIYBXhXmiUf3AaZdss4FBUHrje79BU=; b=AuffrIcoNl9I01UWYoknyOpvB580EjS8rCZZ8CV3juqLKreE093t2CaSq/nCmjOcDlNse+ NNnpT8GEClcr4s4QwKbCcdGF7Aj0zppqUvP2XGFV8rjVmZ36UHjZICbEMs+1lKqwZQhIhC MX/+L0O9Cfkd2ccbVOZ2LUTO8/Ehs1E= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=CEKvMlo8; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="6KYYDi/9"; spf=pass (imf04.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678954693; a=rsa-sha256; cv=none; b=d5ZagzYNlN4lGp3K4+BFPUbryfY/2s1uu6pWtYLO8sNLT/CKb0NMJQ3lmoH3XWCcUOhSu/ 7404osPLMgW5SwbWXO/2bE8quUHR1/ZbxbN/cPxwAGG8vyimCIj1ee5KJb6EJX0eFU4B31 lfNKMmBalO+Y+llXF+307IGnaMiFhDI= 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-out1.suse.de (Postfix) with ESMTPS id 87BCC21A37; Thu, 16 Mar 2023 08:18:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1678954691; 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=hatJpOnSsIAYycIYBXhXmiUf3AaZdss4FBUHrje79BU=; b=CEKvMlo86HMsqhsYEvFOx9bJ/4gkgg6ZuenPJbAd5wdNMhB8hnbBqQ8DEi2v3JHGlGVEpO v9i1oUizAkiZaF395GqZb51NZ46Re6xz8PWCJYlWzyZHjBU2EZB6Z5qqKcMsxn6P/mplQg /Pu5Bka0fMvruR8hGoNVXBf5FoXB9Ow= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1678954691; 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=hatJpOnSsIAYycIYBXhXmiUf3AaZdss4FBUHrje79BU=; b=6KYYDi/9xr3de71WiWcvgrBeGMcGacvfhuQUQn7UkSQaEB0gzFdQ6jVHiXr2hBpkpTRtGf ycwHGf+9Xyd6/yBg== 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 60079133E0; Thu, 16 Mar 2023 08:18:11 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id cvzRFsPQEmShGwAAMHmgww (envelope-from ); Thu, 16 Mar 2023 08:18:11 +0000 Message-ID: Date: Thu, 16 Mar 2023 09:18:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [LSF/MM/BPF TOPIC] SLOB+SLAB allocators removal and future SLUB improvements Content-Language: en-US To: Roman Gushchin Cc: lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-block@vger.kernel.org, bpf@vger.kernel.org, linux-xfs@vger.kernel.org, David Rientjes , Christoph Lameter , Pekka Enberg , Joonsoo Kim , Hyeonggon Yoo <42.hyeyoo@gmail.com> References: <4b9fc9c6-b48c-198f-5f80-811a44737e5f@suse.cz> From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: 3uuz755uu6hcdyqe31esidssdfuuc8cd X-Rspam-User: X-Rspamd-Queue-Id: 2FACD40002 X-Rspamd-Server: rspam06 X-HE-Tag: 1678954692-288833 X-HE-Meta: U2FsdGVkX1/ZyRcgNW2cCs8qxCAhz9MaNDfYcHRSwsxbHxowlNxYEcUKyvZU9P0H12WViRP4cT4DIhcTs+eaA0sOwqyBOfEC324OveomO0YbcjncnQnIsHnh6NDz77Nzl/SB5tv8wak85Kle+M1yhqsG7iWi9uA+41TuX5xe27FZ56IGGP8x157cfw98TstWa7iEcVAu8a9T1tq0MzUsOp6VbD5BthEqCPdJPvaN0Ta+1NJWpatxmUrMggY5iPsF4cGOgAH+JOWjK6r4a8xmX4bmkATF4AEXl3ZLDzWyCM0yYVZ32CcBdcPLb7btrusU6LPtyRqgLorFUCrIFH1smAo7eyje50SROr49z0DJpbyQpl036U3cRPJ7s9V/pj8X4tYMQ1zmgNXZL2oT59nmhycDzR69+Pu9Ie3yrELfMUhzuItEvnr0jHpjjs2PpW9glIKHMHbJ2wqix7unj8UMqM7sAOL3c+KPGLA6h9aveHCknxMM5DMbbAIfbpZ7amo7MjvNSMdDIOlljw23fXI+qD4eaIAhH8fdEWOtYBX30bapdY+FRGJTrrq0HOtlhlbo/+AqWd8oMzpSm6gF2EknYS6FVapqV0cc27X2fc+WRoNM+2cfLOWzfKVljRyWxrftdnIwca9aqc+43wNzBl25IKh2OJzG3wRmQJ89DR9T2SHD+bnRwbxsh4vQ4q6+GUPtfMfRLNMVc4dmtkKjfisk+GM7i4Qq8DU98Re8QyNUBArZlr7jSfYeGWCD1mJI4N4awvqr4wfT7OupDyAL/nUAcVDHe4OcRkVlP3jnc7ywlxXDUOlz1EZnPkDs+O0ntvuL1TqRb+WER1CzGYQ22hIHTApDyz72w90bbyfLEk18ianO5NJdqwufDnXkTMUcj0m33yvZ8MRTaOWqO1yQks9ZS+7N09B9SQ0b2icft0Tjl8kaO34Daeg9PwKo7wdDpvDqf177VKb+B5naVnwhoB1 t54nf5zD ZbcQxVbw+7k9Y0AMNjkrTX5Rqz6AlrDwrY33GK6cO3dXwcDsEJygq3RdNTamdgSUwa6Et/UzDFdRxdoIn4HNvUx+oG518yW3IIqN3Rm4uAUY/QMVDOELdxfY085rPJwW0QLBPhN/nMvGbBy/Bdtq4X+Hs0mFthxQVhLRiWXQ/e1yx45Nf5eyT+urZO68ZpVoUdOPRNzkwxE99SGXU/kYJqfKvhIXYFtjgFcLtBZXR3Z99OoCVU+pMv7fJnrkng5YE9ldLM7i9SOTszMBJNcz1sDXSuasA755nnfoR 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 3/15/23 03:54, Roman Gushchin wrote: > On Tue, Mar 14, 2023 at 09:05:13AM +0100, Vlastimil Babka wrote: >> As you're probably aware, my plan is to get rid of SLOB and SLAB, leaving >> only SLUB going forward. The removal of SLOB seems to be going well, there >> were no objections to the deprecation and I've posted v1 of the removal >> itself [1] so it could be in -next soon. >> >> The immediate benefit of that is that we can allow kfree() (and kfree_rcu()) >> to free objects from kmem_cache_alloc() - something that IIRC at least xfs >> people wanted in the past, and SLOB was incompatible with that. >> >> For SLAB removal I haven't yet heard any objections (but also didn't >> deprecate it yet) but if there are any users due to particular workloads >> doing better with SLAB than SLUB, we can discuss why those would regress and >> what can be done about that in SLUB. >> >> Once we have just one slab allocator in the kernel, we can take a closer >> look at what the users are missing from it that forces them to create own >> allocators (e.g. BPF), and could be considered to be added as a generic >> implementation to SLUB. > > I guess eventually we want to merge the percpu allocator too. What exactly do you mean here, probably not mm/percpu.c which is too different from slab, but some kind of per-cpu object cache on top of slab?