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 CB74EC43217 for ; Tue, 22 Nov 2022 16:33:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2978F6B0071; Tue, 22 Nov 2022 11:33:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 246E66B0073; Tue, 22 Nov 2022 11:33:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E8188E0001; Tue, 22 Nov 2022 11:33:44 -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 F381E6B0071 for ; Tue, 22 Nov 2022 11:33:43 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id ADA8A160E79 for ; Tue, 22 Nov 2022 16:33:43 +0000 (UTC) X-FDA: 80161624326.05.5B7CE37 Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by imf06.hostedemail.com (Postfix) with ESMTP id 1A547180007 for ; Tue, 22 Nov 2022 16:33:41 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7E2685C00E8; Tue, 22 Nov 2022 11:33:41 -0500 (EST) Received: from imap51 ([10.202.2.101]) by compute3.internal (MEProxy); Tue, 22 Nov 2022 11:33:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1669134821; x=1669221221; bh=pc4NDY6xTk HaxDLkLDsVXDo3MteEDUFdw1xpmzDYbfM=; b=ekjInMMw830aiISwkYkDlomkxv LwgcHF5IhLwOJsRoKEzeSJNscc3ql1pD4JCGrH2gqoPQs6shjkndoin4WNLpkCBb YnwL9iW5PMzdZxClFe0lxdB/WqGEXE+4loTAa/dby3XMsR04qkYM3oUMs3IJR+Fq lDqXV/3HXieuXAYGzLWCd66I7gNbTjehxb3IMxUfEMGM8daLgFMxVKoagyMHSilI eNHX5GEgYpWyaFV0GyAyOkFrV1ItLTJW3qqobxCB2A/JHi7mb5RLA4pFprhptC4U VIu9C5JJxRLv+YXdZOSaQpbc8V2XyC9nTC4UC3XGDl0Mf4Ts+SzS4uF/XhSg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1669134821; x=1669221221; bh=pc4NDY6xTkHaxDLkLDsVXDo3MteE DUFdw1xpmzDYbfM=; b=bd6pg2ol1IGfgetol9wblKdazAm8W6HmdfLKdOeFl3Bd BjPosdt5y8G4WMhjCe2sGd1RlptZdCefxQaOoWA1FP+xNL5aKsycMFwa2yTpTCqv 4PF50VRBFXgqVlp33HRW73ZgNTs55OEzowTUOuYvPmL14HZyQsHnW9skqQf7kvXn kapl4//CRWRhlSBm21Hd3xXcMHSJO1F1cVV475CeCT8cxuDKdeqxxxc0iljGAUml nOZUuEjIoDo7bmtn4KGDv64EY9xYYTWu/j7x1ZaVZdzI+5dfWBDLAwPYyjE5j29P NIyflEp+UIys0iXyvXjgCeGhTfmw0iZRR/IoAUgzUQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrheelgdeitdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdetrhhn ugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugesrghrnhgusgdruggvqeenucggtffrrghtth gvrhhnpeffjeetveeifeduffdugeehvdelffdtjedvgfejueffkeejkeetveettddvgfev heenucffohhmrghinhepohhpvghnfihrthdrohhrghenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrhhnugesrghrnhgusgdruggv X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 66842B60086; Tue, 22 Nov 2022 11:33:38 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1115-g8b801eadce-fm-20221102.001-g8b801ead Mime-Version: 1.0 Message-Id: In-Reply-To: <20221121171202.22080-1-vbabka@suse.cz> References: <20221121171202.22080-1-vbabka@suse.cz> Date: Tue, 22 Nov 2022 17:33:17 +0100 From: "Arnd Bergmann" To: "Vlastimil Babka" , "Christoph Lameter" , "David Rientjes" , "Joonsoo Kim" , "Pekka Enberg" Cc: "Hyeonggon Yoo" <42.hyeyoo@gmail.com>, "Roman Gushchin" , "Andrew Morton" , "Linus Torvalds" , "Matthew Wilcox" , patches@lists.linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Aaro Koskinen" , "Christophe Leroy" , "Conor Dooley" , "Damien Le Moal" , "Geert Uytterhoeven" , "Janusz Krzysztofik" , "Jonas Bonn" , "Josh Triplett" , "Kees Cook" , linux-arm-kernel@lists.infradead.org, Linux-OMAP , linux-riscv@lists.infradead.org, linux-sh@vger.kernel.org, openrisc@lists.librecores.org, "Rich Felker" , "Russell King" , "Stafford Horne" , "Stefan Kristiansson" , "Tony Lindgren" , "Yoshinori Sato" Subject: Re: [PATCH 00/12] Introduce CONFIG_SLUB_TINY and deprecate SLOB Content-Type: text/plain ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669134822; a=rsa-sha256; cv=none; b=tO+5pFtzA5bvj3QC7O7QZlmROTN/eE3sXN7SklaNF05hGSHoExopEc/HCbHfQZBEvqA9nR +Wu2UZIsG6vHFlHJH8N8P1QNWCVhM9OR9LpcH0eTVnwIUTtgz5m4WMAXgPSnEoJOkv0VC0 LL9giUgf7sLhGGICRZI/LaI6DHR8s/4= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=arndb.de header.s=fm3 header.b=ekjInMMw; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=bd6pg2ol; spf=pass (imf06.hostedemail.com: domain of arnd@arndb.de designates 66.111.4.25 as permitted sender) smtp.mailfrom=arnd@arndb.de; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669134822; 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=pc4NDY6xTkHaxDLkLDsVXDo3MteEDUFdw1xpmzDYbfM=; b=iHm4Ior5XpxvyGX3A5c+CFIoi5dZJ+L0tFrfOD8Dj5vtrZwCwsSxm0Q4HxbZM5KY373Q94 vbYVVgHx1zxhZFnjzdE/OgvMUBBwfPgcgcpYt+baAqI9tCqXjPbaA6MfQfpISdklGhEz8b noG69ytILIEybpYbQcc6z7fo1lrvIYg= X-Stat-Signature: q4z3rojsc7afnuzzcidwbtq9w6raxrak X-Rspamd-Queue-Id: 1A547180007 X-Rspam-User: Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=arndb.de header.s=fm3 header.b=ekjInMMw; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=bd6pg2ol; spf=pass (imf06.hostedemail.com: domain of arnd@arndb.de designates 66.111.4.25 as permitted sender) smtp.mailfrom=arnd@arndb.de; dmarc=none X-Rspamd-Server: rspam02 X-HE-Tag: 1669134821-154777 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 Mon, Nov 21, 2022, at 18:11, Vlastimil Babka wrote: > > this continues the discussion from [1]. Reasons to remove SLOB are > outlined there and no-one has objected so far. The last patch of this > series therefore deprecates CONFIG_SLOB and updates all the defconfigs > using CONFIG_SLOB=y in the tree. > > There is a k210 board with 8MB RAM where switching to SLUB caused issues > [2] and the lkp bot wasn't also happy about code bloat [3]. To address > both, this series introduces CONFIG_SLUB_TINY to perform some rather > low-hanging fruit modifications to SLUB to reduce its memory overhead. > This seems to have been successful at least in the k210 case [4]. I > consider this as an acceptable tradeoff for getting rid of SLOB. I agree that this is a great success for replacing SLOB on the smallest machines that have 32MB or less and have to run a a highly customized kernel, and this is probably enough to have a drop-in replacement without making any currently working system worse. On the other hand, I have the feeling that we may want something a bit less aggressive than this for machines that are slightly less constrained, in particular when a single kernel needs to scale from 64MB to 512MB, which can happen e.g. on OpenWRT. I have seen a number of reports over the years that suggest that new kernels handle fragmentation and low memory worse than old ones, and it would be great to improve that again. I can imagine those machines wanting to use sysfs in general but not for the slab caches, so having a separate knob to configure out the sysfs stuff could be useful without having to go all the way to SLUB_TINY. For the options that trade off performance against lower fragmentation (MIN/MAX_PARTIAL, KMALLOC_RECLAIM, percpu slabs), I wonder if it's possible to have a boot time default based on the amount of RAM per CPU to have a better tuned system on most cases, rather than having to go to one extreme or the other at compile time. Arnd https://openwrt.org/toh/views/toh_standard_all?datasrt=target&dataflt%5B0%5D=availability_%3DAvailable%202021