On 06.07.20 13:21, Catalin Marinas wrote: > On Mon, Jul 06, 2020 at 10:24:04AM +0200, David Hildenbrand wrote: >> On 03.07.20 17:36, Catalin Marinas wrote: >>> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h >>> index 6be1aa559b1e..276140c94f4a 100644 >>> --- a/include/linux/page-flags.h >>> +++ b/include/linux/page-flags.h >>> @@ -135,6 +135,9 @@ enum pageflags { >>> #if defined(CONFIG_IDLE_PAGE_TRACKING) && defined(CONFIG_64BIT) >>> PG_young, >>> PG_idle, >>> +#endif >>> +#ifdef CONFIG_64BIT >>> + PG_arch_2, >>> #endif >>> __NR_PAGEFLAGS, >> >> People are usually *very* picky when it comes to new page flags. It >> somewhat concerns me that we bump up __NR_PAGEFLAGS for any 64bit arch. >> That feels wrong. > > It was guarded by a specific config option initially but the comments > suggested that it could be dropped for 64-bit architectures: > > https://lore.kernel.org/linux-arm-kernel/20200624113307.6165b3db2404c9d37b870a90@xxxxxxxxxxxxxxxxxxxx/ > > The page flags is indeed a pretty limited resource as it also includes > the sparsemem section, node and zone fields. However, on 64-bit this > should be fine (the sparsemem section is gone with vmemmap support). Right, so 64bit architectures/configs with SPARSEMEM && !SPARSEMEM_VMEMMAP could be affected only. I think mips would be one example where we don't have VMEMMAP support. For most other 64bit architectures (x86_64, s390x, powerpc, ...) SPARSEMEM_VMEMMAP should be the default (although I've seen bug reports/configs where VMEMMAP was disabled). -- Thanks, David / dhildenb