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
