On Mon, Mar 14, 2022 at 6:34 PM Huang, Ying <[email protected]> wrote: > > Yu Zhao <[email protected]> writes: > > > On Mon, Mar 14, 2022 at 2:09 AM Huang, Ying <[email protected]> wrote: > >> > >> Hi, Yu, > >> > >> Yu Zhao <[email protected]> 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.
It is. But LAST_CPUPID_NOT_IN_PAGE_FLAGS should always work but NODE_NOT_IN_PAGE_FLAGS doesn't. _______________________________________________ kernel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
