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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 45922C4332F for ; Tue, 22 Nov 2022 16:34:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Subject:Cc:To:From:Date:References: In-Reply-To:Message-Id:Mime-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=7jjjMW+AdWHmZ06xrsIhFgG+rGAPGkyhNqUYb7vllXo=; b=Cp295OoPWfZzZB 8sI10FQ1eDxpeSg33Fv/KEMcOhI9dss/XV7jakydYERlV+5TohA/uSS8vxCCthQFpFIkf/7Ntg7Yg JHcSeQnvuoZHlZK32A8AiWkYjZHTKjSXTiiqHm+6V1KLx2Z1K3Dd8ZcWlEgqstL36zoHD3sP6omn0 HakTStJFZ3u3jEoeP1glcfpDovWnBlvA/L9m71f6jYnFE66LOc4rQZt3f7prf2SNGWqYKXQJpj/jv 05UmCnT44P8rQI4Bq2ec1DkYQYt86cw0ILj8UTdp+Zd3r0rzleUz+s+cHTIowt5nPpkHbMIsMN3KS MXxx0IndN3JgYhKast5A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oxWDs-00AkqI-Fo; Tue, 22 Nov 2022 16:34:12 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oxWDO-00AkWH-C4; Tue, 22 Nov 2022 16:33:44 +0000 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221122_083342_634687_48F5FE06 X-CRM114-Status: GOOD ( 17.15 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv