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 942F4C43219 for ; Tue, 22 Nov 2022 16:59:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D5FE46B0071; Tue, 22 Nov 2022 11:59:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D0DC46B0073; Tue, 22 Nov 2022 11:59:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BD6418E0001; Tue, 22 Nov 2022 11:59:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id AEC456B0071 for ; Tue, 22 Nov 2022 11:59:20 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 9293780524 for ; Tue, 22 Nov 2022 16:59:20 +0000 (UTC) X-FDA: 80161688880.20.BDE3F48 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf13.hostedemail.com (Postfix) with ESMTP id 0791A2000C for ; Tue, 22 Nov 2022 16:59:18 +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-out2.suse.de (Postfix) with ESMTPS id 680F91F88C; Tue, 22 Nov 2022 16:59:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1669136357; 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=H2atguzqiYlL5qP0R2VMxm0xj35kHN6ayB8+sc0pLb4=; b=iSHuT3UDTOfAlVhdj1j/w/lt9XQcCb6v4pH6irJX8vQahCPufK81fX735lNzQn7lFEqNBE CMogiSE42gU1KvkT/wuN7K5yrbgTwrPz72mnS2v737CpJ9Je3WsHmZfsyG2hJk1mJ18OQ0 AVrwZxFZAHFYTCDuLH97H5+aE+CXmbY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1669136357; 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=H2atguzqiYlL5qP0R2VMxm0xj35kHN6ayB8+sc0pLb4=; b=wWepOSuEdxW0YhOQEJQvnU92jRitq2iAod+tE4DGnRgVKu8+BmKvhFTz1K9OVyneb3j0Mp gT5n5iO+cb1oXCBQ== 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 0574313AA1; Tue, 22 Nov 2022 16:59:17 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id Cr25AOX/fGMcSQAAMHmgww (envelope-from ); Tue, 22 Nov 2022 16:59:17 +0000 Message-ID: Date: Tue, 22 Nov 2022 17:59:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH 00/12] Introduce CONFIG_SLUB_TINY and deprecate SLOB Content-Language: en-US To: Arnd Bergmann , 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 References: <20221121171202.22080-1-vbabka@suse.cz> 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=1669136359; a=rsa-sha256; cv=none; b=WBMHO5ddbiSfQya3N3o4CP/K1LHksLLkPHUwLRW++YWavscbU5RIkYuGFHO08m1o2exMeK KIZJ7kks4cEg5A6J7YTao/nroviQDTP/jLifhe/tywvkBa4tnbmDpC6LW3B0y+M1UDhuy/ GlqsattAMMS/07ojYUYsAfgzG5UAGZQ= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=iSHuT3UD; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=wWepOSuE; dmarc=none; spf=pass (imf13.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669136359; 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=H2atguzqiYlL5qP0R2VMxm0xj35kHN6ayB8+sc0pLb4=; b=WfeyuOM9zQOiVEEGnAhKrGCqlQGA2cCxmrjFBHB1GGaMDulV5SjqOSWSC864G/qGJXDhCL Cp8dPNDb8NWePLpZh5r86vGdIIj7TaIS7z1Bf+EtzJNwi2ijvrkzjDP0/JVZVB87B2oXcK olUjUaEantH2bv0//naPZg+o/7cY60E= X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 0791A2000C X-Rspam-User: Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=iSHuT3UD; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=wWepOSuE; dmarc=none; spf=pass (imf13.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz X-Stat-Signature: 39fp7i3nraox8okiqbyww9fwmbo36kbc X-HE-Tag: 1669136358-459776 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/22/22 17:33, Arnd Bergmann wrote: > 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 see. That would need to study such reports and see if the problem there is actually SLUB, or the page allocator or something else entirely. > 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. Right, but AFAIK that wouldn't save much except some text size and kobjects, so probably negligible for >32MB? > 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. Possible for some of these things, but for others that brings us back to the question what are the actual observed issues. If it's low memory in absolute number of pages, these can help, but if it's fragmentation (and the kind if RAM sizes should have page grouping by mobility enabled), ditching e.g. the KMALLOC_RECLAIM could make it worse. Unfortunately some of these tradeoffs can be rather unpredictable. Thanks, Vlastimil > Arnd > > https://openwrt.org/toh/views/toh_standard_all?datasrt=target&dataflt%5B0%5D=availability_%3DAvailable%202021