| Message ID | 20220302083758.32528-2-songmuchun@bytedance.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | add hugetlb_free_vmemmap sysctl | expand |
On Wed, Mar 02, 2022 at 04:37:56PM +0800, Muchun Song wrote: > If CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON is enabled and the size > of "struct page" is not power of two, we cannot optimize vmemmap pages > of HugeTLB pages. We should disable this feature in this case. The commit log does not descrie what happens if this is left enabled in that case? Is this a fix? Why would it be a fix? Was something failing? How did you spot this issue? What are the consequences of not applying this patch? Luis
On 3/2/22 00:37, Muchun Song wrote: > If CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON is enabled and the size > of "struct page" is not power of two, we cannot optimize vmemmap pages > of HugeTLB pages. We should disable this feature in this case. I'll let you reply to the question from Luis, but IIUC there is no issue today as "struct page" is certainly a power of two. This is more future looking. Correct? > Signed-off-by: Muchun Song <songmuchun@bytedance.com> > --- > mm/hugetlb_vmemmap.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c > index b3118dba0518..836d1117f08b 100644 > --- a/mm/hugetlb_vmemmap.c > +++ b/mm/hugetlb_vmemmap.c > @@ -121,6 +121,17 @@ void __init hugetlb_vmemmap_init(struct hstate *h) > if (!hugetlb_free_vmemmap_enabled()) > return; > > + if (IS_ENABLED(CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON) && > + !is_power_of_2(sizeof(struct page))) { > + /* > + * The hugetlb_free_vmemmap_enabled_key can be enabled when > + * CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON. It should > + * be disabled if "struct page" crosses page boundaries. > + */ > + static_branch_disable(&hugetlb_free_vmemmap_enabled_key); Should we possibly print a warning here as in the routine early_hugetlb_free_vmemmap_param? This is called once per hstate, so perhaps pr_warn_once.
On Thu, Mar 3, 2022 at 8:25 AM Mike Kravetz <mike.kravetz@oracle.com> wrote: > > On 3/2/22 00:37, Muchun Song wrote: > > If CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON is enabled and the size > > of "struct page" is not power of two, we cannot optimize vmemmap pages > > of HugeTLB pages. We should disable this feature in this case. > > I'll let you reply to the question from Luis, but IIUC there is no issue > today as "struct page" is certainly a power of two. This is more future > looking. Correct? Partly right. The size of "struct page" is not the power of two if !CONFIG_MEMCG && CONFIG_SLAB on x86_64. But it is not a conventional configuration nowadays. So it is not a critical problem. I am not sure if a Fixes tag is necessary. > > > Signed-off-by: Muchun Song <songmuchun@bytedance.com> > > --- > > mm/hugetlb_vmemmap.c | 11 +++++++++++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c > > index b3118dba0518..836d1117f08b 100644 > > --- a/mm/hugetlb_vmemmap.c > > +++ b/mm/hugetlb_vmemmap.c > > @@ -121,6 +121,17 @@ void __init hugetlb_vmemmap_init(struct hstate *h) > > if (!hugetlb_free_vmemmap_enabled()) > > return; > > > > + if (IS_ENABLED(CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON) && > > + !is_power_of_2(sizeof(struct page))) { > > + /* > > + * The hugetlb_free_vmemmap_enabled_key can be enabled when > > + * CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON. It should > > + * be disabled if "struct page" crosses page boundaries. > > + */ > > + static_branch_disable(&hugetlb_free_vmemmap_enabled_key); > > Should we possibly print a warning here as in the routine early_hugetlb_free_vmemmap_param? This is called once per hstate, so > perhaps pr_warn_once. Good point. Will do. Thanks.
On Thu, Mar 3, 2022 at 5:21 AM Luis Chamberlain <mcgrof@kernel.org> wrote: > > On Wed, Mar 02, 2022 at 04:37:56PM +0800, Muchun Song wrote: > > If CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON is enabled and the size > > of "struct page" is not power of two, we cannot optimize vmemmap pages > > of HugeTLB pages. We should disable this feature in this case. > > The commit log does not describe what happens if this is left enabled in > that case? Is this a fix? Why would it be a fix? Was something failing? > How did you spot this issue? What are the consequences of not applying > this patch? > If the size of "struct page" is not the power of two and this feature 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_SLAB 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. But we cannot prevent someone from configuring that combined configure. OK, this information should go to the commit log. Will update it. Thanks.
diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c index b3118dba0518..836d1117f08b 100644 --- a/mm/hugetlb_vmemmap.c +++ b/mm/hugetlb_vmemmap.c @@ -121,6 +121,17 @@ void __init hugetlb_vmemmap_init(struct hstate *h) if (!hugetlb_free_vmemmap_enabled()) return; + if (IS_ENABLED(CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON) && + !is_power_of_2(sizeof(struct page))) { + /* + * The hugetlb_free_vmemmap_enabled_key can be enabled when + * CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON. It should + * be disabled if "struct page" crosses page boundaries. + */ + static_branch_disable(&hugetlb_free_vmemmap_enabled_key); + return; + } + vmemmap_pages = (nr_pages * sizeof(struct page)) >> PAGE_SHIFT; /* * The head page is not to be freed to buddy allocator, the other tail
If CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON is enabled and the size of "struct page" is not power of two, we cannot optimize vmemmap pages of HugeTLB pages. We should disable this feature in this case. Signed-off-by: Muchun Song <songmuchun@bytedance.com> --- mm/hugetlb_vmemmap.c | 11 +++++++++++ 1 file changed, 11 insertions(+)