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 D69C3C433FE for ; Wed, 9 Nov 2022 09:10:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 723C98E0001; Wed, 9 Nov 2022 04:10:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D6736B0073; Wed, 9 Nov 2022 04:10:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 59B848E0001; Wed, 9 Nov 2022 04:10:51 -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 49E506B0072 for ; Wed, 9 Nov 2022 04:10:51 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 1F17B808AF for ; Wed, 9 Nov 2022 09:10:51 +0000 (UTC) X-FDA: 80113333902.21.CF034A7 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf03.hostedemail.com (Postfix) with ESMTP id 6995420009 for ; Wed, 9 Nov 2022 09:10:45 +0000 (UTC) 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 130EE21EEA; Wed, 9 Nov 2022 09:09:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1667984983; 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=4rvDAE7ynxS4SjgRq0+PnY4oQgJkKPVoUhifdSQ0G1U=; b=whCkYGYSHp8sgZjH9YqktwAltZO443vH+z259yTeU7m8iS//oeQzr7TDv+/WSAbd00jT48 cnXkzYDrzg5BKnm9BwJo/y52Tcysccd4bRJgdDp1sUaxoxGVHDbWlHdRnu4VsBhasCB21/ NIdWXlfyA6Md1lvtGbCxhqDrzp3hdmI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1667984983; 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=4rvDAE7ynxS4SjgRq0+PnY4oQgJkKPVoUhifdSQ0G1U=; b=Fck9nHcqZ3rxPvaT0Al6ILtulSRwDpOlOPrcv08aV3PNYDXlHD6maHkGJUFvjoRd6OGHJo X+H7/cRV4t+lXXDQ== 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 CBB9D1331F; Wed, 9 Nov 2022 09:09:42 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id gLsHMVZua2PuaQAAMHmgww (envelope-from ); Wed, 09 Nov 2022 09:09:42 +0000 Message-ID: <1823fa9f-f67d-9581-0e6f-55f0c050fcc6@suse.cz> Date: Wed, 9 Nov 2022 10:09:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: Deprecating and removing SLOB Content-Language: en-US To: Yosry Ahmed , Roman Gushchin , David Rientjes , Greg Thelen Cc: Christoph Lameter , Joonsoo Kim , Pekka Enberg , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Matthew Wilcox , Linus Torvalds , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Catalin Marinas , Rustam Kovhaev , Andrew Morton References: From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667985045; a=rsa-sha256; cv=none; b=2sKixsC2wV4UjXbgSaJEH4fqAvNz21gOHA4vLTbxmPIa1eTi9jYik+lBOTNApsNaPFZiMh nmzDzo9eOLiUB7IQRzCA761L8KzetUzZ88oaEpszn/FR/ffG7WfqJXIbxP513mY+BGmMuw Sygv4NGL0WAVM8m2ONv9Eilr9TtYCH0= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=whCkYGYS; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=Fck9nHcq; spf=pass (imf03.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=1667985045; 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=4rvDAE7ynxS4SjgRq0+PnY4oQgJkKPVoUhifdSQ0G1U=; b=VECWP5dz2q5luDpmUWDRt7vkj93AA/y/xSJDv5W1r1mGS2JWFslB/eFq2RE8CJSGl/yqnb bWPqqum5OMY3ZkhOHBTdZ4ZU3fhP5koreva+7Ptxw7I5X25BDe+aaqmhPvmNYH8P684yYl 78zVxfk83TRQa0vXQmUxVgB/PszRXOM= Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=whCkYGYS; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=Fck9nHcq; spf=pass (imf03.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 6995420009 X-Stat-Signature: wfi4iuqypcbxfsu94ufqzpmb7pqhmphz X-HE-Tag: 1667985045-323102 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 11/8/22 21:13, Yosry Ahmed wrote: > On Tue, Nov 8, 2022 at 10:47 AM Roman Gushchin wrote: >> >> On Tue, Nov 08, 2022 at 04:55:29PM +0100, Vlastimil Babka wrote: >> > Hi, >> > >> > as we all know, we currently have three slab allocators. As we discussed at >> > LPC [1], it is my hope that one of these allocators has a future, and two of >> > them do not. >> > >> > The unsurprising reasons include code maintenance burden, other features >> > compatible with only a subset of allocators (or more effort spent on the >> > features), blocking API improvements (more on that below), and my inability >> > to pronounce SLAB and SLUB in a properly distinguishable way, without >> > resorting to spelling out the letters. >> > >> > I think (but may be proven wrong) that SLOB is the easier target of the two >> > to be removed, so I'd like to focus on it first. >> >> Great! >> >> SLOB is not supported by the kernel memory accounting code, so if we'll >> deprecate SLOB, we can remove all those annoying ifndefs. >> >> But I wonder if we can deprecate SLAB too? Or at least use the moment to >> ask every non-SLUB user on why they can't/don't want to use SLUB. >> Are there any known advantages of SLAB over SLUB? Yeah it was my plan to inquire about SLAB next, once SLOB's fate is settled, as I did expect greater resistance there. My hope is that if there are still workloads that benefit from SLAB's percpu arrays, we could e.g. add (per-cache opt-in) percpu arrays to SLUB, as that would be still better than having two different complete implementations. > We use SLAB at Google, but I am not the right person to answer the > question of why we can't/don't use SLUB. Adding Greg here who recently > looked into this and might have answers. I see David is already > tagged, he might have a good answer as well. Yeah, Google folks were indeed against removing SLAB due to such workloads in the past discussions. >> >> Also, for memory-constrained users we might want to add some guide on how >> to configure SLUB to minimize the memory footprint. >> >> Thank you! >> >> Roman >>