Messages in this thread | | | Date | Thu, 14 Apr 2022 11:10:01 +0800 | From | Muchun Song <> | Subject | Re: [PATCH v8 1/4] mm: hugetlb_vmemmap: introduce CONFIG_HUGETLB_PAGE_HAS_OPTIMIZE_VMEMMAP |
| |
On Wed, Apr 13, 2022 at 12:08:04PM -0700, Andrew Morton wrote: > On Wed, 13 Apr 2022 22:47:45 +0800 Muchun Song <songmuchun@bytedance.com> wrote: > > > If the size of "struct page" is not the power of two but with the feature > > of minimizing overhead of struct page associated with each HugeTLB is > > enabled, then the vmemmap pages of HugeTLB will be corrupted after > > remapping (panic is about to happen in theory). But this only exists when > > !CONFIG_MEMCG && !CONFIG_SLUB on x86_64. However, it is not a conventional > > configuration nowadays. So it is not a real word issue, just the result > > of a code review. > > The patch does add a whole bunch of tricky junk to address something > which won't happen. How about we simply disable > CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP if (!CONFIG_MEMCG && > !CONFIG_SLUB)? >
I'm afraid not. The size of 'struct page' also depends on LAST_CPUPID_NOT_IN_PAGE_FLAGS which could be defined when CONFIG_NODES_SHIFT or CONFIG_KASAN_SW_TAGS or CONFIG_NR_CPUS is configured with a large value. Then the size would be more than 64 bytes.
Seems like the approach [1] is more simple and feasible, which also could prevent the users from doing unexpected configurations, however, it is objected by Masahiro. Shall we look back at the approach again?
Thanks.
| |