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 735F7C4332F for ; Tue, 22 Nov 2022 17:16:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B339F6B0071; Tue, 22 Nov 2022 12:16:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AE20D6B0073; Tue, 22 Nov 2022 12:16:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 982D68E0001; Tue, 22 Nov 2022 12:16:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 852606B0071 for ; Tue, 22 Nov 2022 12:16:11 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 39603806A1 for ; Tue, 22 Nov 2022 17:16:11 +0000 (UTC) X-FDA: 80161731342.13.F2C5F1F Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by imf03.hostedemail.com (Postfix) with ESMTP id 7FDD920014 for ; Tue, 22 Nov 2022 17:16:09 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 412F65C01AC; Tue, 22 Nov 2022 12:16:07 -0500 (EST) Received: from imap51 ([10.202.2.101]) by compute3.internal (MEProxy); Tue, 22 Nov 2022 12:16:07 -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=1669137367; x=1669223767; bh=AWib7uk/pX ojLTP6WLnsRKQNx+DKIkZTOrXloBCRaME=; b=lySZ7U8uKnWn00jTXtr9CAy5eX nv56f5UzD8Tk1XQ/zM5Lhx6iJpKUBacT8Jhv8GyD2PflS6Y7GxJQc0fIKYqg5Oes CFa1i/Ts0YaZ3w+29HTSOtSLJVf8UyxvgO7Elc+4A1sD1p/Xc15Cgj/ipv+7sC75 6w/wVc+YoF9EFV6ZnauvYJWW3dZBEdWUU3Bunbq5pUvgvqvufeUJEzM47bRam58J c3BOM4tOLUQkAGfA/RhyWi1+/qHvJbvC8bLwEEGaDCDs9qV6wxZFKoq3UYhXxQKt Wh8d/wv3tWb9gfqRvidRS+ZMd1z1j9zWUlznP4LRf6uszZiJKJUYJDZHHY8Q== 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=1669137367; x=1669223767; bh=AWib7uk/pXojLTP6WLnsRKQNx+DK IkZTOrXloBCRaME=; b=WsG7hmw+LKirM0tmH9Kzn5cWIv1cpT8+lNht2XAQJ9s3 4ZLi37KXbwyfZUymR+BePagoJCdji1Vzcj0n80TQIde9wB6INMz6g6O95orGjmgQ D4kmajLzD+hdqXIR6sGDItFx17483bKqA/prajubW26vU7eE2HfQ48F4RU3AbTOn BflQWRTk2zMsv9br6one4vxpVJ+2Kq+zgKTclR29Zf4FJW/LONRJf+GU2SCd5pYG J4BngUHmANTkgBSU86Eb3htMc55hA4qxKx5rSTTKWS1MsK5pY95N8jw9lUbptr/n 4Z8nSzdK1pAXa5mMpKlxS3WdFwiL2He3irWZfBm6bA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrheelgdeilecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdetrhhn ugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugesrghrnhgusgdruggvqeenucggtffrrghtth gvrhhnpeffheeugeetiefhgeethfejgfdtuefggeejleehjeeutefhfeeggefhkedtkeet ffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrh hnugesrghrnhgusgdruggv X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 30CBAB60086; Tue, 22 Nov 2022 12:16:03 -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: <501fbee3-cd3d-461c-9c79-0a5f2d1382b6@app.fastmail.com> In-Reply-To: References: <20221121171202.22080-1-vbabka@suse.cz> Date: Tue, 22 Nov 2022 18:15:39 +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=1669137369; a=rsa-sha256; cv=none; b=iFb41cuO2dx+u2EqLuyg91bT8qrgy+QfuQ+GrfBtxq/xRozdnPcD6QnUheYpdH1SoJuHeX 9L5osVD1LEQ14a1n5G1FhQEf62+vTFLlKljk+TuZg/Beg3QE4sbOtzFZvUxgUXJ+C8ru4H TAsVDIjsDYlt8MSYT11fdke1ip9D/fo= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=arndb.de header.s=fm3 header.b=lySZ7U8u; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=WsG7hmw+; dmarc=none; spf=pass (imf03.hostedemail.com: domain of arnd@arndb.de designates 66.111.4.25 as permitted sender) smtp.mailfrom=arnd@arndb.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669137369; 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=AWib7uk/pXojLTP6WLnsRKQNx+DKIkZTOrXloBCRaME=; b=Tdi4Cexwq8FketgeVRsKXf0SmXXzA39NSp76ZP/YEHhN+XKBvrjuuvusI57C/m7AQW7EZa Ah4OPjLKIIQ991Jdxlw2wz400YkOAsnp8WTk6dNxmz/kuhdFBpXz9P2W0zadOnQBcLcyjC NE979QAFKbX4bA18JP4UpO6eSgqQzoc= Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=arndb.de header.s=fm3 header.b=lySZ7U8u; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=WsG7hmw+; dmarc=none; spf=pass (imf03.hostedemail.com: domain of arnd@arndb.de designates 66.111.4.25 as permitted sender) smtp.mailfrom=arnd@arndb.de X-Stat-Signature: ct1eks1ierc78q4cob58rg4mwd6bk5fp X-Rspamd-Queue-Id: 7FDD920014 X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1669137369-794764 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 22, 2022, at 17:59, Vlastimil Babka wrote: > On 11/22/22 17:33, Arnd Bergmann wrote: >> On Mon, Nov 21, 2022, at 18:11, Vlastimil Babka wrote: >> 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? Makes sense, I assume you have a better idea of how much this could save. I'm not at all worried about the .text size, but my initial guess was that the metadata for sysfs would be noticeable. >> 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. Are there any obvious wins on memory uage? I would guess that it would be safe to e.g. ditch percpu slabs when running with less 128MB per CPU, and the MIN/MAX_PARTIAL values could easily be a function of the number of pages in total or per cpu, whichever makes most sense. As a side-effect, those could also grow slightly larger on huge systems by scaling them with log2(totalpages). Arnd