Messages in this thread | | | From | "Huang, Ying" <> | Subject | Re: [PATCH v9 05/14] mm: multi-gen LRU: groundwork | Date | Tue, 15 Mar 2022 08:34:18 +0800 |
| |
Yu Zhao <yuzhao@google.com> writes:
> On Mon, Mar 14, 2022 at 2:09 AM Huang, Ying <ying.huang@intel.com> wrote: >> >> Hi, Yu, >> >> Yu Zhao <yuzhao@google.com> 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]
| |