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 88C9EC433EF for ; Mon, 21 Mar 2022 18:58:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E68C66B0073; Mon, 21 Mar 2022 14:58:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E19588D0002; Mon, 21 Mar 2022 14:58:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CBB028D0001; Mon, 21 Mar 2022 14:58:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id BDF006B0073 for ; Mon, 21 Mar 2022 14:58:21 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 67D8180251 for ; Mon, 21 Mar 2022 18:58:21 +0000 (UTC) X-FDA: 79269304002.08.8BF939C Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) by imf22.hostedemail.com (Postfix) with ESMTP id DD1B3C001A for ; Mon, 21 Mar 2022 18:58:20 +0000 (UTC) Received: by mail-ej1-f43.google.com with SMTP id qa43so31638719ejc.12 for ; Mon, 21 Mar 2022 11:58:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6aLAHA+A+XxV/kMRfZhDtEhgsmAuTureOTlZFDIWkzs=; b=RAs6AL/UX0IZmCfYsp+mS0REBjvbfAP9hY2CyUN4KyfRWSfSzksNloMYP4BgI/poIb 1CEyzpKzIcDWFxObGBBnUe0oBA2ZfrcNsmnxIWG/Scl3uUNCn451xVn/oPZOKLR+zLOo ROZeWfkvRkCEfuNpuBmUaUrWMJzAc8Oxqxo7w5NpY3iLtwP1bxWaNzuj4lmFtbx/fRjU iRH8Xu5UD7TiWxwYcnGW8MxWEog4G3jH098c5qIxg404g1fkWRQFkrgGhjqkIuSBLgLw BRuX/yJJvcAXF7AGLmJxHQTVeEihUfWlU6c+vOxH4kb6XS/j4X15qIrxwOXe3E/lIybh NI5A== X-Gm-Message-State: AOAM533eGKGJnleKBjw+pgbtVk7Qqfo5EvR3HnzspDgXiDE9Gkyz5XnW arjs6d+CjrgpXQCUhehTAr3etlicgfkIFdnVf+Ahww== X-Google-Smtp-Source: ABdhPJw43iRiq+D1zfQ0J+MApKYivTG9ixyQabZWo7Hz7p1g9hAkNUhsYf004S6F+kC1U+OJfh6k71JDJTdo67TQ4cg= X-Received: by 2002:a17:907:3e98:b0:6d7:7c21:529f with SMTP id hs24-20020a1709073e9800b006d77c21529fmr22525233ejc.104.1647889098743; Mon, 21 Mar 2022 11:58:18 -0700 (PDT) MIME-Version: 1.0 References: <20220309021230.721028-1-yuzhao@google.com> <20220309021230.721028-6-yuzhao@google.com> <875yoh552i.fsf@yhuang6-desk2.ccr.corp.intel.com> In-Reply-To: From: Justin Forbes Date: Mon, 21 Mar 2022 13:58:07 -0500 Message-ID: Subject: Re: [PATCH v9 05/14] mm: multi-gen LRU: groundwork To: Yu Zhao Cc: "Huang, Ying" , kernel , kernel-team@lists.ubuntu.com, Andrew Morton , Linus Torvalds , Andi Kleen , Aneesh Kumar , Catalin Marinas , Dave Hansen , Hillf Danton , Jens Axboe , Jesse Barnes , Johannes Weiner , Jonathan Corbet , Matthew Wilcox , Mel Gorman , Michael Larabel , Michal Hocko , Mike Rapoport , Rik van Riel , Vlastimil Babka , Will Deacon , Linux ARM , "open list:DOCUMENTATION" , linux-kernel , Linux-MM , Kernel Page Reclaim v2 , "the arch/x86 maintainers" , Brian Geffon , Jan Alexander Steffens , Oleksandr Natalenko , Steven Barrett , Suleiman Souhlal , Daniel Byrne , Donald Carr , =?UTF-8?Q?Holger_Hoffst=C3=A4tte?= , Konstantin Kharlamov , Shuang Zhai , Sofia Trinh , Vaibhav Jain Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: DD1B3C001A X-Stat-Signature: 3acpbp1is63hye6n5y1u96g88fmz1zi6 X-Rspam-User: Authentication-Results: imf22.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=fedoraproject.org (policy=none); spf=pass (imf22.hostedemail.com: domain of jmforbes@linuxtx.org designates 209.85.218.43 as permitted sender) smtp.mailfrom=jmforbes@linuxtx.org X-HE-Tag: 1647889100-916831 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 Mon, Mar 14, 2022 at 4:30 AM Yu Zhao wrote: > > On Mon, Mar 14, 2022 at 2:09 AM Huang, Ying wrote: > > > > Hi, Yu, > > > > Yu Zhao writes: > > > diff --git a/mm/Kconfig b/mm/Kconfig > > > index 3326ee3903f3..747ab1690bcf 100644 > > > --- a/mm/Kconfig > > > +++ b/mm/Kconfig > > > @@ -892,6 +892,16 @@ config ANON_VMA_NAME > > > area from being merged with adjacent virtual memory areas due to the > > > difference in their name. > > > > > > +# the multi-gen LRU { > > > +config LRU_GEN > > > + bool "Multi-Gen LRU" > > > + depends on MMU > > > + # the following options can use up the spare bits in page flags > > > + depends on !MAXSMP && (64BIT || !SPARSEMEM || SPARSEMEM_VMEMMAP) > > > > LRU_GEN depends on !MAXSMP. So, What is the maximum NR_CPUS supported > > by LRU_GEN? > > LRU_GEN doesn't really care about NR_CPUS. IOW, it doesn't impose a > max number. The dependency is with NODES_SHIFT selected by MAXSMP: > default "10" if MAXSMP > This combined with LAST_CPUPID_SHIFT can exhaust the spare bits in page flags. > > MAXSMP is meant for kernel developers to test their code, and it > should not be used in production [1]. But some distros unfortunately > ship kernels built with this option, e.g., Fedora and Ubuntu. And > their users reported build errors to me after they applied MGLRU on > those kernels ("Not enough bits in page flags"). Let me add Fedora and > Ubuntu to this thread. > > Fedora and Ubuntu, > > Could you please clarify if there is a reason to ship kernels built > with MAXSMP? Otherwise, please consider disabling this option. Thanks. > > As per above, MAXSMP enables ridiculously large numbers of CPUs and > NUMA nodes for testing purposes. It is detrimental to performance, > e.g., CPUMASK_OFFSTACK. It was enabled for Fedora, and RHEL because we did need more than 512 CPUs, originally only in RHEL until SGI (years ago) complained that they were testing very large machines with Fedora. The testing done on RHEL showed that the performance impact was minimal. For a very long time we had MAXSMP off and carried a patch which allowed us to turn on CPUMASK_OFFSTACK without debugging because there was supposed to be "something else" coming. In 2019 we gave up, dropped that patch and just turned on MAXSMP. I do not have any metrics for how often someone runs Fedora on a ridiculously large machine these days, but I would guess that number is not 0. Justin > [1] https://lore.kernel.org/lkml/20131106055634.GA24044@gmail.com/ >