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 CD234C433FE for ; Tue, 8 Nov 2022 21:53:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 30C806B0072; Tue, 8 Nov 2022 16:53:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2BCE46B0073; Tue, 8 Nov 2022 16:53:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1840D8E0001; Tue, 8 Nov 2022 16:53:55 -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 08A546B0072 for ; Tue, 8 Nov 2022 16:53:55 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id C304EA0987 for ; Tue, 8 Nov 2022 21:53:54 +0000 (UTC) X-FDA: 80111627988.26.C2A07CD Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by imf23.hostedemail.com (Postfix) with ESMTP id 435ED14001A for ; Tue, 8 Nov 2022 21:53:46 +0000 (UTC) Received: by mail-lf1-f48.google.com with SMTP id a29so4498590lfj.9 for ; Tue, 08 Nov 2022 13:53:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=mZFYs8/zJjnbjhxTKlu/w82IWm0RAU48MKw/y8nRI+A=; b=mhDFXjVqtUOa9ADmdT3AyKxlu9yrLNznmsAqiT/urYmLB5C5JlSB2vwN0krfoC9fyA orfVh86H0lh+U9RieTNZKk20UdD6ApuyCbEEJehRxBGPaQj9d44Q+kG6SMwdl2jpjJwb kh+g6MbuP1lAqfh4ECVfKGkX3XBXVH+dJd3ZWySFEHT1Uesu2Mi0jxW/6N1x9mjgM9mx 0Lm/w6shCcvrUGhLoY6y2d9MYpQ3aVExCzItoXq/DRazSkayN6xXjISbYg+u5oGuKLmr tvunTpllbeBaCcXFRCliaHmOCMMGO0WfVFfZT5BXf8fsMf3Nlk6sclYgGXff/K7k0+zv CExw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=mZFYs8/zJjnbjhxTKlu/w82IWm0RAU48MKw/y8nRI+A=; b=Wct/Q/PiVzww9xjzzNyttHZC1Rop5kVKQoxlazM6h81ve/fOG19ZISYuEyfv9S0w8J A2IMXbtB7UP4hlQTXV0/a6mRqzIlWEMRoDPL4fvAMk85MwdMuFGUMn7Zmji3wsdIzde9 YPBf2to9Ga0H9II2mgiiJh0OAUJgmzZ9NaCkyNi6pFa5MdzszsUVEahdNj6Ai459Yi5G yLgC58JifZlDQYyQWMgFh8oDU56YbDhEZ8lu0NThwECiRmJUHbh27AJ/H/b6b4c/pNsy rn0MJqkxlFoq7kRuMuRsyc8/HGuFojIw8NrtOJU1jp5U2ISjl6XKUa1/TerSuXGkTAkh cLdw== X-Gm-Message-State: ACrzQf2nxZwg4g+cuKQS++0hPQU+inheEyguEXUTjQZKjenq6ihH6TiT W3UaWg1lyDnUjHat9VWxuNo1oLQXqPjx0e194x1+DFMzTeXN6g== X-Google-Smtp-Source: AMsMyM5Prj/Xj102CMb75AxvuB6WgPWaojsX+xM0xgkodxuTmeo7H90R++xOrlixi2Jh2ZqCmo5RKF7YvufuC+HL7k8= X-Received: by 2002:a17:907:761b:b0:7a3:86dd:d330 with SMTP id jx27-20020a170907761b00b007a386ddd330mr54176947ejc.34.1667943911502; Tue, 08 Nov 2022 13:45:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Pasha Tatashin Date: Tue, 8 Nov 2022 16:44:34 -0500 Message-ID: Subject: Re: Deprecating and removing SLOB To: Vlastimil Babka Cc: Christoph Lameter , David Rientjes , Joonsoo Kim , Pekka Enberg , 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" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667944426; a=rsa-sha256; cv=none; b=h9wCFnjbMEOlh6DiNGTdCHodjpZr803lOWrrRHz0Y0qkjggqrQMmXOujqRX1VVDIPRteKx BDAoEr1lVoiLz4YGlOFOpFrKAYdeBZZoPlFLBb+pgf7BYBH859lwqYq5UYDHHf0q03zJa/ Ae7Idffewsnm7EhHDi30vJspncFz1wA= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=mhDFXjVq; spf=pass (imf23.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667944426; 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=mZFYs8/zJjnbjhxTKlu/w82IWm0RAU48MKw/y8nRI+A=; b=xskWDeo28CKQsrw9jXhgVt5ByuTd9WPAGCkwwJMW4UFc1tBad8go75pGo5pQ8XM8y/cFA3 oNhDGad63pC+41lHJE7cfrwgFp1FSL6W3gjwhd4rWhsA0lihJx314Fn5TxKEQWGHWGYYl8 LBkfIlVL0zki16sLwbFeqyrmdFMiiys= X-Stat-Signature: xjmccf7ydbqg8w7ybyx79m3hn1953rur X-Rspam-User: Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=mhDFXjVq; spf=pass (imf23.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=none X-Rspamd-Queue-Id: 435ED14001A X-Rspamd-Server: rspam09 X-HE-Tag: 1667944426-616259 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 Tue, Nov 8, 2022 at 10:55 AM 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. > > 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. I am all for removing SLOB. There are some devices with configs where SLOB is enabled by default. Perhaps, the owners/maintainers of those devices/configs should be included into this thread: tatashin@soleen:~/x/linux$ git grep SLOB=y arch/arm/configs/clps711x_defconfig:CONFIG_SLOB=y arch/arm/configs/collie_defconfig:CONFIG_SLOB=y arch/arm/configs/multi_v4t_defconfig:CONFIG_SLOB=y arch/arm/configs/omap1_defconfig:CONFIG_SLOB=y arch/arm/configs/pxa_defconfig:CONFIG_SLOB=y arch/arm/configs/tct_hammer_defconfig:CONFIG_SLOB=y arch/arm/configs/xcep_defconfig:CONFIG_SLOB=y arch/openrisc/configs/or1ksim_defconfig:CONFIG_SLOB=y arch/openrisc/configs/simple_smp_defconfig:CONFIG_SLOB=y arch/riscv/configs/nommu_k210_defconfig:CONFIG_SLOB=y arch/riscv/configs/nommu_k210_sdcard_defconfig:CONFIG_SLOB=y arch/riscv/configs/nommu_virt_defconfig:CONFIG_SLOB=y arch/sh/configs/rsk7201_defconfig:CONFIG_SLOB=y arch/sh/configs/rsk7203_defconfig:CONFIG_SLOB=y arch/sh/configs/se7206_defconfig:CONFIG_SLOB=y arch/sh/configs/shmin_defconfig:CONFIG_SLOB=y arch/sh/configs/shx3_defconfig:CONFIG_SLOB=y kernel/configs/tiny.config:CONFIG_SLOB=y > > - 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/ > > >