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 87D2BC4167B for ; Mon, 27 Nov 2023 00:27:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DCD4E6B02E9; Sun, 26 Nov 2023 19:27:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D7D166B02EC; Sun, 26 Nov 2023 19:27:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C45916B02FC; Sun, 26 Nov 2023 19:27:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B49BB6B02E9 for ; Sun, 26 Nov 2023 19:27:03 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 938D71201C8 for ; Mon, 27 Nov 2023 00:27:03 +0000 (UTC) X-FDA: 81501844326.23.C68F297 Received: from mail-vs1-f44.google.com (mail-vs1-f44.google.com [209.85.217.44]) by imf18.hostedemail.com (Postfix) with ESMTP id CA7AD1C0003 for ; Mon, 27 Nov 2023 00:27:01 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=SBpXqfay; spf=pass (imf18.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.217.44 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701044821; a=rsa-sha256; cv=none; b=QV3luQ2jsvTIvGj2lvUjT1FTBJmbIPemmO/fyfMQxdic7XZifiowOW5QuhHxyq0CK+25do lIlLYs8be6t/ZCuNL/ZyH/7xImfnFMOBva8obvfS3R2x6C+HDfqB5AHN/Ut1Rte/eTDJHu 58kPc0Rlh9Ug6PpQiR5jsyEaWsHoWbc= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=SBpXqfay; spf=pass (imf18.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.217.44 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701044821; 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=Hy/ENHor4F15xijuhqLOiJEFPoW/G6S/ww33a/cC+1M=; b=me93taaKI7Z9AX7jNfiy2cMCfQtmDeLYHeG5Oiqh41VgISgaWXFHr2aiWmbXCH+86PckBc zvfY7uXY1lbl/xJ1myoE++4jv7npZv3inpk0LVE6OJ9tPZzTLxQ5AIKXfqrG21mtrCRzpo isByYHO+fVmd/tgrrgl3YtEJDe/gRpA= Received: by mail-vs1-f44.google.com with SMTP id ada2fe7eead31-462d4a5b889so808061137.2 for ; Sun, 26 Nov 2023 16:27:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701044821; x=1701649621; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Hy/ENHor4F15xijuhqLOiJEFPoW/G6S/ww33a/cC+1M=; b=SBpXqfayxw0bhpswNbrW/2TtngahxvSCa0fQHzArg8Bs9TmK5tXvXQ9FliQfNGJYv4 QFedULMAFH1TTQnakibtl7yOXl9kqgfR3GZ1F7WFBP9xBGRYxBGVuSxOrPJqn/oZIRl2 9p//XZcBThW7qHIbnNzma3yTV6S2vnXd3YmZ+ib/Ol/DF3jo1JQhZcU5gc3HnAOBj3fS S9EASJA1kV7mXAmByuSzvKWFkgaAEHwrkypHjC8XDFWDaiadG7/Ph1arXzZ8ADzV3sSl iBiXXSNoDXKHGaH166bGMNZfLq4SaZswLdUpwVnvznLJepii+xHsbE2G/ceoWL2tr7oU 8L3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701044821; x=1701649621; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Hy/ENHor4F15xijuhqLOiJEFPoW/G6S/ww33a/cC+1M=; b=EY+DDCVzMzHdPB8IEA/9bjItMSlJNuicSNGHXvdhc9HAq9mBJfqioCRaQeqteBUmUk RutQELtia+M+w2fOInpyP+4ocX4QJ+u2XmoVbSe7b7FzSOCQYULfulgXiDU37KnaGLDi irMdhmwkVwYwYJBckLnS/v6PcEudXjNrkw49TJTTmi5Y+hmKgSX7uA3ScOeeRROWbeg5 j6NI9UndZ76146vgdbvClmWqvluOS790itk6EtSsS8xFmaXmwVZFJbngXw2EA43iY3Rh hnynujrOOip3tTn55mkOhJglL8fy2C+bZwLs5ZmdPlCNclXhMVvXS7zbz8W2wcoWCHtL x8vQ== X-Gm-Message-State: AOJu0YwkHiENCz8nkopsFO6Luzt6FaT3KGSLoWxgV4MJ2xul/Qw2qEo0 NEeIiAmucaJHTBaJ5M3VQ8Ip+QtUuQ51NRVMrf0= X-Google-Smtp-Source: AGHT+IFk0G48eLp0w2WCnyNsF9N/JMyM6eZ/+Pb0gFe5OD/imxQTwdyb4Hpc+PrmBHn9zbM5NDSKaDg8xWNcAXHWO1c= X-Received: by 2002:a05:6102:17d1:b0:45f:a41:b405 with SMTP id jf17-20020a05610217d100b0045f0a41b405mr9678005vsb.21.1701044820765; Sun, 26 Nov 2023 16:27:00 -0800 (PST) MIME-Version: 1.0 References: <20231122143603.85297-1-sxwjean@me.com> <7512b350-4317-21a0-fab3-4101bc4d8f7a@suse.cz> In-Reply-To: <7512b350-4317-21a0-fab3-4101bc4d8f7a@suse.cz> From: Hyeonggon Yoo <42.hyeyoo@gmail.com> Date: Mon, 27 Nov 2023 09:26:55 +0900 Message-ID: Subject: Re: [PATCH v2] Documentation: kernel-parameters: remove slab_max_order and noaliencache To: Vlastimil Babka 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: CA7AD1C0003 X-Stat-Signature: 6ap5mjbxon315mfmprttrtkeao1ticyd X-Rspam-User: X-HE-Tag: 1701044821-24779 X-HE-Meta: U2FsdGVkX18Hf17c5O2CAkN/E8ffHrWMpSeaamJHmy3D8r9LhW9JaFeSTHFMah+L7JM8205m2peh2WbhXE4E1IBaDbnXIMZ/9gwZdJINsWcXwpqIaQPYeQGczLFUDWmZYYM+ceNa5L2q5WTkAHwT/SFams+yXRPIuJeiB/0ylcYE9hu86Uhx8q0psXBzO68M7LlKT54/Jr/TMalEEOLmyYhAUVvUgIRsBePFAdG1fiJx5SizTdPOhOPmXc4g4hZkfv3S6FM0wzoDN2IQZPO5whZhAfl8H+OJj/1gq1X5ffCAsHBP/GLJLoA12og7AjtJ8dtp/DyXcixeqa6a1oP8wYEEBl7KxAl2OPfAPQd6CKSfqY9ZDySiC0m18qyDOU7IRgIiHYxhzc5T+WeEJyZx4fNbAeuRHcR2YiREDjlVkJbkvz4XX9Ndti2lyXJESgE22o/4D3uMpz/iaHrvcRjpu290Z/YVidMeP1QrFx+3FRXjEG7hms9REOQGQ4cmwAFZDTCq1Td+7WMrHYqcubtPVGHcUFCAABu3BDUAh8ZFWRbmH5NouvTyF681ykNOWzNhUtye0B9Dpp/87m7QWs79EwKnbKfjRifQjcbeGYCl9oaunYYOTe7OM/fgt1dtfRSXAWeyI/2tOmy7zlaMvTRba45jNh4Qc59qOal/3NQBCVFyN18WBe9qwZsA1gBQZnNyO/fqvdTa2McjBsr5Hh+A554t7my0pmxS8KamZekxbiZDf/i7ICCe2NImpCFyxALTTkP73oXL9/bUyQoR59mCtsD8BMZeeMrlVstiw7R4zu5IhouREAalOIS5DhJGxkngS0RntU7QtJOJbloSnoZUoNhjBMAI5fJ3qJynM873MT+wWGK59D0ROsr1fniyN9V2/wQ4+fHRWYyMR5Cx0cWsJ8BLebKoSrvNNPaM89dgvMS4GqKcGfEMHWBhmbBKnsmPbvs72GmY3n4vpudYbFf ldpARCne 5nGi6NATlthxqpPG6HeIaBtcqNEqocrFk+qtXQJB/x4z4Ja1pcOHzWVAf44ymzFekJn3Gl3iB0VKSejTTojzZdGHvrM/ZsuIYnxYXz/U5pk+sU8Xe/gkt+dUUfJaOGvR7rkJdIFZjigh2mqjfryOMejlZc8EA47ClBky+Tc/6lIrsOa7SBmw7pvKIC392urAa0u9cpevFrtUHWjG7UwKatjkK4sbiOKD9g7BYb/JrIA/fqI+Shqxu+dXBIuutZR+YwanJdiepBp7z7cOQaMmo2dB/FnFi6EECvjHTMbf6lGKAB2XlE9ctcaJEMOJyuYcYxbgLPMkgNTccQWmXnWAtDQzXNX2fn00DHnXevMZaZ7DAL6Is6zf8JAO/+ll5ytMvEQH2r9zrBXTKNxvCeV2tP26QjX1Y0ZFsub7XisRKSkpx7tJ+ocMONXjBs/sqBoV8hPopyr5XbJi7bo1TfUPLU2220o65KAmaoqMOth40w19/9uVrfR9j2u6FgYvdaAxr9y8PpUmpWsi/sK5v3DHsG1ueg2Kno6VUCpBWDpqm7/QBP9qMwNU9I+zI8w== 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 Fri, Nov 24, 2023 at 8:24=E2=80=AFPM Vlastimil Babka wr= ote: > > On 11/22/23 15:36, sxwjean@me.com wrote: > > From: Xiongwei Song > > > > Since slab allocator has already been removed. There is no users about > > slab_max_order and noaliencache, so let's remove them. > > > > Signed-off-by: Xiongwei Song > > --- > > v2: Hyeonggon Yoo <42.hyeyoo@gmail.com> suggested that noaliencache sho= uld be > > removed too. Here adding this change. The patch is based on [1]. > > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/lo= g/?h=3Dslab-remove-slab-v2r1 > > > > v1: https://lore.kernel.org/linux-mm/20231120091214.150502-1-sxwjean@me= .com/T/#m55ebb45851bc86d650baf65dfe8296d33c5b1126 > > --- > > Documentation/admin-guide/kernel-parameters.txt | 10 ---------- > > 1 file changed, 10 deletions(-) > > > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Document= ation/admin-guide/kernel-parameters.txt > > index 65731b060e3f..d56a5beefe24 100644 > > --- a/Documentation/admin-guide/kernel-parameters.txt > > +++ b/Documentation/admin-guide/kernel-parameters.txt > > @@ -3740,10 +3740,6 @@ > > no5lvl [X86-64,RISCV] Disable 5-level paging mode. Force= s > > kernel to use 4-level paging instead. > > > > - noaliencache [MM, NUMA, SLAB] Disables the allocation of alien > > - caches in the slab allocator. Saves per-node mem= ory, > > - but will impact performance. > > No question about this one, can be deleted. > > > - > > noalign [KNL,ARM] > > > > noaltinstr [S390] Disables alternative instructions patching > > @@ -5887,12 +5883,6 @@ > > own. > > For more information see Documentation/mm/slub.rs= t. > > > > - slab_max_order=3D [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, eve= n > if some became interchangeable aliases later (slab/slub_nomerge), some no= t. 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_nocmpxc= hg as it's an implementation-specific feature. > 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) and 2) only using slub_$param for slub-specific params would be enough? > > - > > slub_debug[=3Doptions[,slabs][;[options[,slabs]]...] [MM, SL= UB] > > Enabling slub_debug allows one to determine the > > culprit if slab objects become corrupted. Enablin= g >