On Thu, Jan 14, 2021 at 8:18 AM Mike Kravetz <mike.kravetz@xxxxxxxxxx> wrote: > > On 1/6/21 6:19 AM, Muchun Song wrote: > > For HugeTLB page, there are more metadata to save in the struct page. > > But the head struct page cannot meet our needs, so we have to abuse > > other tail struct page to store the metadata. In order to avoid > > conflicts caused by subsequent use of more tail struct pages, we can > > gather these discrete indexes of tail struct page. In this case, it > > will be easier to add a new tail page index later. > > > > There are only (RESERVE_VMEMMAP_SIZE / sizeof(struct page)) struct > > page structs that can be used when CONFIG_HUGETLB_PAGE_FREE_VMEMMAP, > > so add a BUILD_BUG_ON to catch invalid usage of the tail struct page. > > > > Signed-off-by: Muchun Song <songmuchun@xxxxxxxxxxxxx> > > Reviewed-by: Oscar Salvador <osalvador@xxxxxxx> > > --- > > include/linux/hugetlb.h | 14 ++++++++++++++ > > include/linux/hugetlb_cgroup.h | 15 +++++++++------ > > mm/hugetlb.c | 25 ++++++++++++------------- > > mm/hugetlb_vmemmap.c | 8 ++++++++ > > 4 files changed, 43 insertions(+), 19 deletions(-) > > My apologies! I did not get to this patch in previous versions of the > series. My "RFC create hugetlb flags to consolidate state" was done > before I even noticed your efforts here. > > At least we agree the metadata could be better organized. :) > > IMO, using page.private of the head page to consolidate flags will be > easier to manage. So, I would like to use that. Agree. Using page.private to manage the page flag is a good choice. When your RFC patch is applied, I will rebase it and rework this patch. > > The BUILD_BUG_ON in this patch makes sense. > -- > Mike Kravetz
