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 C7C30C46CA0 for ; Mon, 27 Nov 2023 11:52:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 658F46B02D8; Mon, 27 Nov 2023 06:52:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 609696B02D9; Mon, 27 Nov 2023 06:52:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D15F6B02DA; Mon, 27 Nov 2023 06:52:32 -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 3E6CE6B02D8 for ; Mon, 27 Nov 2023 06:52:32 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 237C01A01E8 for ; Mon, 27 Nov 2023 11:52:32 +0000 (UTC) X-FDA: 81503571744.23.F3FD4C1 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf06.hostedemail.com (Postfix) with ESMTP id 98AFD180013 for ; Mon, 27 Nov 2023 11:52:29 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=vshiPyiu; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=GOO3Xvsd; dmarc=none; spf=pass (imf06.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 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=1701085950; 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=nrobSf+3Er3g99gK4Amny1sZq4F2LlsryKeWhP499C0=; b=lMmcnLIy36rirNHoN+vYJu0Hh+vhUdT0x8PYoog0gmyHbAbb8ZT/kHFIWUGWwGRmjT08dd 8q6md8V80VrICDx45L0Yxru+m3IGwJ+NxKyr7JJZo7ldSoCj+dI7ZKD2rUzlFnV24Wxb7w 29+zB4H7BUI+mZhh+EG5GyA54Nc9Aj8= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=vshiPyiu; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=GOO3Xvsd; dmarc=none; spf=pass (imf06.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701085950; a=rsa-sha256; cv=none; b=3LbV5mk9lzHyr/6QKE3DPFKfCF/0IUeFmdR7xCnMi1tyHTdG3oJSsFH6AU7cw4m6+sOqJF 0SeVtt5XZ7HaPk7NyHjTZaRbhZYqk/mHrk387bMYvan5aUiMXkh9pOIwwpseNOumByYDdJ wCx6TAK7nSfaaXOPl0QeSW9N7vZSSUo= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id CB9B221D12; Mon, 27 Nov 2023 11:52:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1701085947; 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=nrobSf+3Er3g99gK4Amny1sZq4F2LlsryKeWhP499C0=; b=vshiPyiu+o3JNtf85M6mVSw5oHHMSalqRLOtWS2YDzjWG5giL6ye65kkExzJIG2aI0/W82 uBj/METULwO4Y3ojU31biAB46zhXKZMgvQwGcEvN4E1mcUtVu7JdoG7LiR1chztE9mdsdb PbPdNPzc+9wNCro3I3zkYhKyBnYAnQE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1701085947; 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=nrobSf+3Er3g99gK4Amny1sZq4F2LlsryKeWhP499C0=; b=GOO3XvsdHvyfc5kG7Lfj+uc8OV0fTpxmE8ww2CFi3gqqdA25jOEPOaF10MpLN+Agq1V2MC x3JotkM8rXe5jeBA== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id AD1E61379A; Mon, 27 Nov 2023 11:52:27 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id kVfqKfuCZGXScgAAD6G6ig (envelope-from ); Mon, 27 Nov 2023 11:52:27 +0000 Message-ID: <3cb4c839-caa4-5c6e-1672-6498124d3930@suse.cz> Date: Mon, 27 Nov 2023 12:52:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH v2] Documentation: kernel-parameters: remove slab_max_order and noaliencache Content-Language: en-US To: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: sxwjean@me.com, linux-mm@kvack.org, cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, roman.gushchin@linux.dev, corbet@lwn.net, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Xiongwei Song References: <20231122143603.85297-1-sxwjean@me.com> <7512b350-4317-21a0-fab3-4101bc4d8f7a@suse.cz> From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 98AFD180013 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: ar3aiamwjsmtup8u78ypyboqjbe8gk3c X-HE-Tag: 1701085949-414643 X-HE-Meta: U2FsdGVkX18ssNxskSUn63AZOP+uf1jyMVPtTfGOLkx28RXFw/6AuXaWcq0GeLnE5iRTF+7lq9b+/kI/+mcOF21cw8uvXRfrIryf95CO10QM0v/4OylMGdyCyoujpF6ABLV+vxqKe9ZTLkLTkIOvCCxZ3EIXFrB+SvMPC0ZEzlLrU6eDRokq5+YBQnVrk78Dhj7F+18gE6Y5DT8B2XqICSVKb1vBG+k7mbqbMT39hNc4rNYLNAg89uObAMdbbiD7qYyfkZIRUCq837fxJX6dLPxv4QpyI8B1ebUKotRfwDygn11mGHSH8b6gh5b191kLkm/YxZBBm2lAhfzZ7LC/riHmUcGZ3oPCdTuBI8Wryop4XQNnplmc6gFgloLs4QSt/SOXGS1lyr4xS06Ev7uX7YgDIYR0lGePXqDtziFhMOyOWRLsEBhevw4eg/D7WnfAFzxHKrhIeUapW9Ui8DYdCax4YPsScQQfpjN6TPv1aNYRHqit0AswsZmtO66v4XaroToPbpCNY1WvyzIEtrA9GoZO3BhITwNfD1gi17atjnKrOnYyPLfOef2Ab/VjCRWRm5DtTMbUTo6/2eY1EA1qVZfJUN5CcKWRUvTqWdb6xGkXEDmsq+wlHQP24MFt5JGDgfHV35IYcL/0EcjJb7vmJDwxNUQQS0urbaJeyobEsZPcLPOdfB1kpf3zQ4wmidULLRv+1m7ETa3p46wx1u9QFNw+0vIZHHphIm5xmrwYvRcBmfyhsFOwtzPSj5SyELXXYLOIzZMTfekz6zxO7RJ9rx1xG4iZ0Oh8Al3ZuiK0x4VHAgU0cfBwxOPJvhaKGx7/12QnKJcyzKjkd4z6HYNbxz4GsZijOXLtihJZeuJN3IJ/YOGD08SpeuM2NLzRBMFnzMC3zzREg9ecq3o0ZacPfgLNSJ+K2jDMhART6mWf4waIh76EqafDPObeRA6/DQ9YECHpJO3EOnK40YhvbfQ KNs0Kx6D Hf4xwcL+EmpcejuiKxS2kfLEwziyvHJDw235sojwh+5p11q3Nk8ZD4W0ZZt0k2m1RZXtO7ifSLYjOf+vn8EsCZBFawTUrFJ/UVdLgyoUb0Gv69kqiNEHZbdeB6Snku7+AfKmrLsX1uo2Ccy7bOzWhcIV32nhaEvUSjwdLtBjW08DwKTGmeMNW1y1O/GKqD5MVPm9e3wFDMHag6to9CQTWP1PG1900JrdgSfEJ0auYowL7Dxm2AYy35Zd6hKsZRPeZOsCJdlNzRPzgRW7KT/Cm+A8m2l3qgYkMaTQHT3Iw8Kk3vVOwMmJc4kU8JnzU9b7xqmckYLwIa2gIes8CE707ZU0dAfO9Cn4guBEX/X++bFYVu/rApm3+7DseD0pRa2IydP/5KCuzxIEr6DI= 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: List-Subscribe: List-Unsubscribe: On 11/27/23 01:26, Hyeonggon Yoo wrote: > On Fri, Nov 24, 2023 at 8:24 PM Vlastimil Babka wrote: >> > - >> > noalign [KNL,ARM] >> > >> > noaltinstr [S390] Disables alternative instructions patching >> > @@ -5887,12 +5883,6 @@ >> > own. >> > For more information see Documentation/mm/slub.rst. >> > >> > - slab_max_order= [MM, SLAB] >> > - Determines the maximum allowed order for slabs. >> > - A high setting may cause OOMs due to memory >> > - fragmentation. Defaults to 1 for systems with >> > - more than 32MB of RAM, 0 otherwise. >> >> I think here we should consider the long-term plan first. It's a bit >> unfortunate (in hindsight) SLUB brought its own prefix of parameters, even >> if some became interchangeable aliases later (slab/slub_nomerge), some not. > > Good point, thank you for pointing them out! > >> I think it would be best to unify them, and consider the string "slub" an >> implementation detail of the general "slab allocator" term going forward. > > So slab_{nomerge,min_objects,min_order, ...etc} are common to the > concept of slab so slab_$param will be appropriate. > > But if we add something like slub_nocmpxchg later, it would be slub_nocmpxchg > as it's an implementation-specific feature. Hm but we're going to have only one implementation and I hope that won't change again (the implementation could furter evolve, even with large changes, but not split into separate selection again). So I'd rather use slab_$thing even for parameters that look like implementation specific. >> So what I'd propose is that we change all parameters to accept a >> "slab_$param" as a primary and documented name (and the description can >> contain just [MM] tag, no [SLAB] or [SLUB] needed), with "slub_$param" is >> also accepted as an alias where it exists today, and there's just a note >> that the slub_$param name is also accepted in the description of the >> canonical parameter, not in a separate description. > > No reason not to do it. > >> Then maybe in a few >> years we can mark the old names as deprecated and start issuing low-key >> warnings (while still accepting them), and in 10 years maybe remove them >> completely. Thoughts? > > That might be the safest way to remove a kernel parameter but should > we remove them? > Probably 1) allowing both slub_$param and slab_$param for general > parameters (forever) Well we can certainly try deprecate them in few years, just to avoid cruft. But it's not critical in case that's rejected for some reason. > and 2) only using slub_$param for slub-specific params would be enough? > >> > - >> > slub_debug[=options[,slabs][;[options[,slabs]]...] [MM, SLUB] >> > Enabling slub_debug allows one to determine the >> > culprit if slab objects become corrupted. Enabling >>