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 AE01EC433EF for ; Tue, 15 Mar 2022 00:34:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ED03B8D0002; Mon, 14 Mar 2022 20:34:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E802C8D0001; Mon, 14 Mar 2022 20:34:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CF9718D0002; Mon, 14 Mar 2022 20:34:31 -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 C20E38D0001 for ; Mon, 14 Mar 2022 20:34:31 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 830B560470 for ; Tue, 15 Mar 2022 00:34:31 +0000 (UTC) X-FDA: 79244749542.13.71CF5C8 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf20.hostedemail.com (Postfix) with ESMTP id C9D2A1C000B for ; Tue, 15 Mar 2022 00:34:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1647304470; x=1678840470; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=XQ4rcun35JKs85E4Y+M1ZfvI2sKujSfLpEMpVPq0Spg=; b=Lc3x0X6GBvRDvZm84cXZCLeJSqF4rA0cuqodqJJbFYh5+K0Kwpz3LXsA f47B8fDG/oFu+PHlmsvQclNRhNCm/iLpXapZx8lKtAH9S8RSnt9YfjgoO GiUJi1ToiXdlith4Codxrc8BT3s+0uF7twF5pAUww8ps8eRreaQIy+3hq SqoT8RUci9pRCx1OB9Y+AwQS/lQ10G/msQdvRQZK2LxbHc6B7IiDzus5M weg8mGYCIP2o7+22Yew5wR9+c3Be9q65XZoey+chpKGwiLSLt5iOmt72m POxHGeu+YfXouMykb6t8/1h3Wsma1WTOn1vE3YvI6YSeL6nraF1JLzdg0 g==; X-IronPort-AV: E=McAfee;i="6200,9189,10286"; a="238348049" X-IronPort-AV: E=Sophos;i="5.90,181,1643702400"; d="scan'208";a="238348049" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Mar 2022 17:34:29 -0700 X-IronPort-AV: E=Sophos;i="5.90,181,1643702400"; d="scan'208";a="713957692" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.239.13.94]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Mar 2022 17:34:20 -0700 From: "Huang, Ying" To: Yu Zhao Cc: kernel@lists.fedoraproject.org, 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 , Holger =?utf-8?Q?Hoffst=C3=A4tte?= , Konstantin Kharlamov , Shuang Zhai , Sofia Trinh , Vaibhav Jain Subject: Re: [PATCH v9 05/14] mm: multi-gen LRU: groundwork References: <20220309021230.721028-1-yuzhao@google.com> <20220309021230.721028-6-yuzhao@google.com> <875yoh552i.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Tue, 15 Mar 2022 08:34:18 +0800 In-Reply-To: (Yu Zhao's message of "Mon, 14 Mar 2022 03:30:31 -0600") Message-ID: <87mths3vg5.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Queue-Id: C9D2A1C000B X-Stat-Signature: qg3ffmn159rud6uzyd5w1p89fp5pdyy6 X-Rspam-User: Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Lc3x0X6G; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf20.hostedemail.com: domain of ying.huang@intel.com has no SPF policy when checking 134.134.136.126) smtp.mailfrom=ying.huang@intel.com X-Rspamd-Server: rspam02 X-HE-Tag: 1647304470-338780 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: Yu Zhao writes: > 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. >From the following code snippets from page-flags-layout.h, LAST_CPUPID_SHIFT is related to NR_CPUS instead of NODES_SHIFT. #define LAST__PID_SHIFT 8 #define LAST__PID_MASK ((1 << LAST__PID_SHIFT)-1) #define LAST__CPU_SHIFT NR_CPUS_BITS #define LAST__CPU_MASK ((1 << LAST__CPU_SHIFT)-1) #define LAST_CPUPID_SHIFT (LAST__PID_SHIFT+LAST__CPU_SHIFT) Best Regards, Huang, Ying [snip]