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 766C8C4332F for ; Tue, 8 Nov 2022 15:55:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B6CA56B0072; Tue, 8 Nov 2022 10:55:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B1CCE6B0073; Tue, 8 Nov 2022 10:55:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E4916B0074; Tue, 8 Nov 2022 10:55:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 92B006B0072 for ; Tue, 8 Nov 2022 10:55:33 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4C90916108E for ; Tue, 8 Nov 2022 15:55:33 +0000 (UTC) X-FDA: 80110724946.03.06DB1C4 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf26.hostedemail.com (Postfix) with ESMTP id 7EC1014000C for ; Tue, 8 Nov 2022 15:55:31 +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 C614822820; Tue, 8 Nov 2022 15:55:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1667922929; 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; bh=x225nnYb0m09aWzTrP5L/lIuqsHhwz3iYeUvx0RAQbE=; b=2TUd1duHrMxjmsXjOrJC1sgCrA93tMgcKEoproEVUEJjH6LRxPKdUkcvEwWQ1qWhE18JYX 6LusQy3n1Oq4nLruRxcaViEpG7lF6xJuoxYaJjpXTOa+sT0l2BePev7DsVh0u4RynrhulK 2uXKMJv8w8/IxEsQCrh4iK3v96ta088= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1667922929; 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; bh=x225nnYb0m09aWzTrP5L/lIuqsHhwz3iYeUvx0RAQbE=; b=/91LnrYhnleouDDDUrPyM0ks+2JjungbJpLVn6PZctxF6KFxT5Z+TS/m/M4smYLXWEEWQs P6MndwuLRL6W7hCw== 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 812CD139F1; Tue, 8 Nov 2022 15:55:29 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id dzHFHfF7amO0ZwAAMHmgww (envelope-from ); Tue, 08 Nov 2022 15:55:29 +0000 Message-ID: Date: Tue, 8 Nov 2022 16:55:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Content-Language: en-US From: Vlastimil Babka Subject: Deprecating and removing SLOB To: Christoph Lameter , David Rientjes , Joonsoo Kim , Pekka Enberg Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>, Matthew Wilcox , Roman Gushchin , Linus Torvalds , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Catalin Marinas , Rustam Kovhaev , Andrew Morton Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667922931; 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: references:dkim-signature; bh=x225nnYb0m09aWzTrP5L/lIuqsHhwz3iYeUvx0RAQbE=; b=7YqybWGvbBwShbQLIrj/SjUNc6Ntf115fvkxAYckncpYXhGyciMYOX4HczcevE8VIW2BeP hBl9Sg1zbjp6HlX3rQ27zGgiE/XpKw5s5xG3J2KBkgJT/7OX4URDbIkoydHninha5wqCZR bwW4nzIEHfKhulgTyh9rOjcVdPuhrm8= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=2TUd1duH; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="/91LnrYh"; spf=pass (imf26.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=1667922931; a=rsa-sha256; cv=none; b=EhuN6rlj4vyzUKq9tz5Qljqdb9lVeHqASxAwSsvh657RA09jDvRxZ7YMtrru2o7CefGl5U jz4LlvlPa5CfD/ZAoWWPa0O0aiOHSE/i4Mzct2K62hhpmkD+EUIBe4ic8oRoYyvvN2srGg Zpr5vtECUF3L7NxWbfn2Cp6icT3T6/s= Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=2TUd1duH; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="/91LnrYh"; spf=pass (imf26.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: rspam03 X-Rspamd-Queue-Id: 7EC1014000C X-Stat-Signature: hi6dn6inoc661wjiyugcgz8kxm65z15b X-HE-Tag: 1667922931-456798 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: 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. I believe SLOB can be removed because: - AFAIK nobody really uses it? It strives for minimal memory footprint by putting all objects together, which has its CPU performance costs (locking, lack of percpu caching, searching for free space...). I'm not aware of any "tiny linux" deployment that opts for this. For example, OpenWRT seems to use SLUB and the devices these days have e.g. 128MB RAM, not up to 16 MB anymore. I've heard anecdotes that the performance SLOB impact is too much for those who tried. Googling for "CONFIG_SLOB=y" yielded nothing useful. - Last time we discussed it [2], it seemed SLUB memory requirements can be brought very close to SLOB's if needed. Of course it can never have as small footprint as SLOB due to separate kmem_caches, but the difference is not that significant, unless somebody still tries to use Linux on very tiny systems (goes back to the previous point). Besides the smaller maintenance burden, removing SLOB would allow us to do a useful API improvement - the ability to use kfree() for both objects allocated by kmalloc() and kmem_cache_alloc(). Currently the latter has to be freed by kmem_cache_free(), passing a kmem_cache pointer in addition to the object pointer. With SLUB and SLAB, it is however possible to use kfree() instead, as the kmalloc caches and the rest of kmem_caches are the same and kfree() can lookup the kmem_cache from object pointer easily for any of those. XFS has apparently did that for years without anyone noticing it's broken on SLOB [3], and legitimizing and expanding this would help some use cases beside XFS (IIRC Matthew mentioned rcu-based freeing for example). However for SLOB to support kfree() on all allocations, it would need to store object size of allocated objects (which it currently does only for kmalloc() objects, prepending a size header to the object), but for kmem_cache_alloc() allocations as well. This has been attempted in the thread [3] but it bloats the memory usage, especially on architectures with large ARCH_KMALLOC_MINALIGN, where the prepended header basically has to occupy the whole ARCH_KMALLOC_MINALIGN block to be DMA safe. There are ongoing efforts to reduce this minalign, but the memory footprint would still increase, going against the purpose of SLOB, so again it would be easier if we could just remove it. So with this thread I'm interested in hearing arguments/use cases for keeping SLOB. There might be obviously users of SLOB whom this conversation will not reach, so I assume the eventual next step would be to deprecate it in a way that those users are notified when building a new kernel and can raise their voice then. Is there a good proven way how to do that for a config option like this one? Thanks, Vlastimil [1] https://lpc.events/event/16/contributions/1272/ - slides in the slabs.pdf linked there [2] https://lore.kernel.org/all/20211017135708.GA8442@kvm.asia-northeast3-a.c.our-ratio-313919.internal/#t [3] https://lore.kernel.org/all/20210930044202.GP2361455@dread.disaster.area/