| Message ID | 20230906112605.2286994-5-usama.arif@bytedance.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mm: hugetlb: Skip initialization of gigantic tail struct pages if freed by HVO | expand |
On 09/06/23 12:26, Usama Arif wrote: > The new boot flow when it comes to initialization of gigantic pages > is as follows: > - At boot time, for a gigantic page during __alloc_bootmem_hugepage, > the region after the first struct page is marked as noinit. > - This results in only the first struct page to be > initialized in reserve_bootmem_region. As the tail struct pages are > not initialized at this point, there can be a significant saving > in boot time if HVO succeeds later on. > - Later on in the boot, the head page is prepped and the first > HUGETLB_VMEMMAP_RESERVE_SIZE / sizeof(struct page) - 1 tail struct pages > are initialized. > - HVO is attempted. If it is not successful, then the rest of the > tail struct pages are initialized. If it is successful, no more > tail struct pages need to be initialized saving significant boot time. Code looks reasonable. Quick question. On systems where HVO is disabled, we will still go through this new boot flow and init hugetlb tail pages later in boot (gather_bootmem_prealloc). Correct? If yes, will there be a noticeable change in performance from the current flow with HVO disabled? My concern would be allocating a large number of gigantic pages at boot (TB or more).
On 06/09/2023 19:10, Mike Kravetz wrote: > On 09/06/23 12:26, Usama Arif wrote: >> The new boot flow when it comes to initialization of gigantic pages >> is as follows: >> - At boot time, for a gigantic page during __alloc_bootmem_hugepage, >> the region after the first struct page is marked as noinit. >> - This results in only the first struct page to be >> initialized in reserve_bootmem_region. As the tail struct pages are >> not initialized at this point, there can be a significant saving >> in boot time if HVO succeeds later on. >> - Later on in the boot, the head page is prepped and the first >> HUGETLB_VMEMMAP_RESERVE_SIZE / sizeof(struct page) - 1 tail struct pages >> are initialized. >> - HVO is attempted. If it is not successful, then the rest of the >> tail struct pages are initialized. If it is successful, no more >> tail struct pages need to be initialized saving significant boot time. > > Code looks reasonable. Quick question. > > On systems where HVO is disabled, we will still go through this new boot > flow and init hugetlb tail pages later in boot (gather_bootmem_prealloc). > Correct? > If yes, will there be a noticeable change in performance from the current > flow with HVO disabled? My concern would be allocating a large number of > gigantic pages at boot (TB or more). > Thanks for the review. The patch moves the initialization of struct pages backing hugepage from reserve_bootmem_region to a bit later on in the boot to gather_bootmem_prealloc. When HVO is disabled, there will be no difference in time taken to boot with or without this patch series, as 262144 struct pages per gigantic page (for x86) are still going to be initialized, just in a different place.
On 09/06/23 22:27, Usama Arif wrote: > > > On 06/09/2023 19:10, Mike Kravetz wrote: > > On 09/06/23 12:26, Usama Arif wrote: > > > The new boot flow when it comes to initialization of gigantic pages > > > is as follows: > > > - At boot time, for a gigantic page during __alloc_bootmem_hugepage, > > > the region after the first struct page is marked as noinit. > > > - This results in only the first struct page to be > > > initialized in reserve_bootmem_region. As the tail struct pages are > > > not initialized at this point, there can be a significant saving > > > in boot time if HVO succeeds later on. > > > - Later on in the boot, the head page is prepped and the first > > > HUGETLB_VMEMMAP_RESERVE_SIZE / sizeof(struct page) - 1 tail struct pages > > > are initialized. > > > - HVO is attempted. If it is not successful, then the rest of the > > > tail struct pages are initialized. If it is successful, no more > > > tail struct pages need to be initialized saving significant boot time. > > > > Code looks reasonable. Quick question. > > > > On systems where HVO is disabled, we will still go through this new boot > > flow and init hugetlb tail pages later in boot (gather_bootmem_prealloc). > > Correct? > > If yes, will there be a noticeable change in performance from the current > > flow with HVO disabled? My concern would be allocating a large number of > > gigantic pages at boot (TB or more). > > > > Thanks for the review. > > The patch moves the initialization of struct pages backing hugepage from > reserve_bootmem_region to a bit later on in the boot to > gather_bootmem_prealloc. When HVO is disabled, there will be no difference > in time taken to boot with or without this patch series, as 262144 struct > pages per gigantic page (for x86) are still going to be initialized, just in > a different place. I seem to recall that 'normal' deferred struct page initialization was done in parallel as the result of these series: https://lore.kernel.org/linux-mm/20171013173214.27300-1-pasha.tatashin@oracle.com/ https://lore.kernel.org/linux-mm/20200527173608.2885243-1-daniel.m.jordan@oracle.com/#t and perhaps others. My thought is that we lose that parallel initialization when it is being done as part of hugetlb fall back initialization. Does that make sense? Or am I missing something? I do not have any proof that things will be slower. That is just something I was thinking about.
On 06/09/2023 22:59, Mike Kravetz wrote: > On 09/06/23 22:27, Usama Arif wrote: >> >> >> On 06/09/2023 19:10, Mike Kravetz wrote: >>> On 09/06/23 12:26, Usama Arif wrote: >>>> The new boot flow when it comes to initialization of gigantic pages >>>> is as follows: >>>> - At boot time, for a gigantic page during __alloc_bootmem_hugepage, >>>> the region after the first struct page is marked as noinit. >>>> - This results in only the first struct page to be >>>> initialized in reserve_bootmem_region. As the tail struct pages are >>>> not initialized at this point, there can be a significant saving >>>> in boot time if HVO succeeds later on. >>>> - Later on in the boot, the head page is prepped and the first >>>> HUGETLB_VMEMMAP_RESERVE_SIZE / sizeof(struct page) - 1 tail struct pages >>>> are initialized. >>>> - HVO is attempted. If it is not successful, then the rest of the >>>> tail struct pages are initialized. If it is successful, no more >>>> tail struct pages need to be initialized saving significant boot time. >>> >>> Code looks reasonable. Quick question. >>> >>> On systems where HVO is disabled, we will still go through this new boot >>> flow and init hugetlb tail pages later in boot (gather_bootmem_prealloc). >>> Correct? >>> If yes, will there be a noticeable change in performance from the current >>> flow with HVO disabled? My concern would be allocating a large number of >>> gigantic pages at boot (TB or more). >>> >> >> Thanks for the review. >> >> The patch moves the initialization of struct pages backing hugepage from >> reserve_bootmem_region to a bit later on in the boot to >> gather_bootmem_prealloc. When HVO is disabled, there will be no difference >> in time taken to boot with or without this patch series, as 262144 struct >> pages per gigantic page (for x86) are still going to be initialized, just in >> a different place. > > I seem to recall that 'normal' deferred struct page initialization was > done in parallel as the result of these series: > https://lore.kernel.org/linux-mm/20171013173214.27300-1-pasha.tatashin@oracle.com/ > https://lore.kernel.org/linux-mm/20200527173608.2885243-1-daniel.m.jordan@oracle.com/#t > and perhaps others. > > My thought is that we lose that parallel initialization when it is being > done as part of hugetlb fall back initialization. > > Does that make sense? Or am I missing something? I do not have any proof > that things will be slower. That is just something I was thinking about. The patches for deferring struct page initialization did not cover the struct pages for gigantic pages. With CONFIG_DEFERRED_STRUCT_PAGE_INIT enabled, the function call taken during boot without these patches is: [A1] mm_core_init-> mem_init-> memblock_free_all-> free_low_memory_core_early-> memmap_init_reserved_pages-> reserve_bootmem_region-> initialize *all* struct pages of a gigantic page serially (DEFERRED_STRUCT_PAGE_INIT is enabled). The pfn of the struct pages > NODE_DATA(nid)->first_deferred_pfn which means this cannot be deferred. then later on in the boot: [A2] hugetlb_init-> gather_bootmem_prealloc-> prep_compound_gigantic_folio-> prepare *all* the struct pages to be part of a gigantic page (freezing page ref count, setting compound head, etc for all struct pages) With CONFIG_DEFERRED_STRUCT_PAGE_INIT enabled, the function call taken during boot with these patches is: [B1] mm_core_init->...reserve_bootmem_region-> initialize head struct page only. then later on in the boot: [B2] hugetlb_init-> gather_bootmem_prealloc-> [B21] initialize only 64 tail struct pages if HVO passes. [B22] If HVO fails initialize all tail struct pages. Each of A1, A2 and B22 are for loops going over 262144 struct pages per hugepage. So without these patches, the work done is 262144*2 (A1+A2) per hugepage during boot, even with CONFIG_DEFERRED_STRUCT_PAGE_INIT as its not deferred. With these patches, the work done is either 1 + 64 (B1+B21) if HVO is enabled or 1 + 262144 (B1+B22) if HVO is disabled. With CONFIG_DEFERRED_STRUCT_PAGE_INIT enabled, the times taken to boot till init process when allocating 500 1G hugeppages are: - with these patches, HVO enabled: 1.32 seconds [B1 + B21] - with patches, HVO disabled: 2.15 seconds [B1 + B22] - without patches, HVO enabled: 3.90 seconds [A1 + A2 + HVO] - without patches, HVO disabled: 3.58 seconds [A1 + A2]
On 09/07/23 11:14, Usama Arif wrote: > > > On 06/09/2023 22:59, Mike Kravetz wrote: > > On 09/06/23 22:27, Usama Arif wrote: > > > > > > > > > On 06/09/2023 19:10, Mike Kravetz wrote: > > > > On 09/06/23 12:26, Usama Arif wrote: > > > > > The new boot flow when it comes to initialization of gigantic pages > > > > > is as follows: > > > > > - At boot time, for a gigantic page during __alloc_bootmem_hugepage, > > > > > the region after the first struct page is marked as noinit. > > > > > - This results in only the first struct page to be > > > > > initialized in reserve_bootmem_region. As the tail struct pages are > > > > > not initialized at this point, there can be a significant saving > > > > > in boot time if HVO succeeds later on. > > > > > - Later on in the boot, the head page is prepped and the first > > > > > HUGETLB_VMEMMAP_RESERVE_SIZE / sizeof(struct page) - 1 tail struct pages > > > > > are initialized. > > > > > - HVO is attempted. If it is not successful, then the rest of the > > > > > tail struct pages are initialized. If it is successful, no more > > > > > tail struct pages need to be initialized saving significant boot time. > > > > > > > > Code looks reasonable. Quick question. > > > > > > > > On systems where HVO is disabled, we will still go through this new boot > > > > flow and init hugetlb tail pages later in boot (gather_bootmem_prealloc). > > > > Correct? > > > > If yes, will there be a noticeable change in performance from the current > > > > flow with HVO disabled? My concern would be allocating a large number of > > > > gigantic pages at boot (TB or more). > > > > > > > > > > Thanks for the review. > > > > > > The patch moves the initialization of struct pages backing hugepage from > > > reserve_bootmem_region to a bit later on in the boot to > > > gather_bootmem_prealloc. When HVO is disabled, there will be no difference > > > in time taken to boot with or without this patch series, as 262144 struct > > > pages per gigantic page (for x86) are still going to be initialized, just in > > > a different place. > > > > I seem to recall that 'normal' deferred struct page initialization was > > done in parallel as the result of these series: > > https://lore.kernel.org/linux-mm/20171013173214.27300-1-pasha.tatashin@oracle.com/ > > https://lore.kernel.org/linux-mm/20200527173608.2885243-1-daniel.m.jordan@oracle.com/#t > > and perhaps others. > > > > My thought is that we lose that parallel initialization when it is being > > done as part of hugetlb fall back initialization. > > > > Does that make sense? Or am I missing something? I do not have any proof > > that things will be slower. That is just something I was thinking about. > > The patches for deferring struct page initialization did not cover the > struct pages for gigantic pages. > > With CONFIG_DEFERRED_STRUCT_PAGE_INIT enabled, the function call taken > during boot without these patches is: > > [A1] mm_core_init-> mem_init-> memblock_free_all-> > free_low_memory_core_early-> memmap_init_reserved_pages-> > reserve_bootmem_region-> initialize *all* struct pages of a gigantic page > serially (DEFERRED_STRUCT_PAGE_INIT is enabled). > The pfn of the struct pages > NODE_DATA(nid)->first_deferred_pfn which means > this cannot be deferred. Thank you very much! I am not very familiar with the init process and just wanted to make sure that no possible performance regression was introduced. In will make some specific comments on the patch, but as previously stated it looks pretty good.
On 09/06/23 12:26, Usama Arif wrote: > The new boot flow when it comes to initialization of gigantic pages > is as follows: > - At boot time, for a gigantic page during __alloc_bootmem_hugepage, > the region after the first struct page is marked as noinit. > - This results in only the first struct page to be > initialized in reserve_bootmem_region. As the tail struct pages are > not initialized at this point, there can be a significant saving > in boot time if HVO succeeds later on. > - Later on in the boot, the head page is prepped and the first > HUGETLB_VMEMMAP_RESERVE_SIZE / sizeof(struct page) - 1 tail struct pages > are initialized. > - HVO is attempted. If it is not successful, then the rest of the > tail struct pages are initialized. If it is successful, no more > tail struct pages need to be initialized saving significant boot time. > > Signed-off-by: Usama Arif <usama.arif@bytedance.com> > --- > mm/hugetlb.c | 61 +++++++++++++++++++++++++++++++++++++------- > mm/hugetlb_vmemmap.c | 2 +- > mm/hugetlb_vmemmap.h | 9 ++++--- > mm/internal.h | 3 +++ > mm/mm_init.c | 2 +- > 5 files changed, 62 insertions(+), 15 deletions(-) As mentioned, in general this looks good. One small point below. > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index c32ca241df4b..540e0386514e 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -3169,6 +3169,15 @@ int __alloc_bootmem_huge_page(struct hstate *h, int nid) > } > > found: > + > + /* > + * Only initialize the head struct page in memmap_init_reserved_pages, > + * rest of the struct pages will be initialized by the HugeTLB subsystem itself. > + * The head struct page is used to get folio information by the HugeTLB > + * subsystem like zone id and node id. > + */ > + memblock_reserved_mark_noinit(virt_to_phys((void *)m + PAGE_SIZE), > + huge_page_size(h) - PAGE_SIZE); > /* Put them into a private list first because mem_map is not up yet */ > INIT_LIST_HEAD(&m->list); > list_add(&m->list, &huge_boot_pages); > @@ -3176,6 +3185,40 @@ int __alloc_bootmem_huge_page(struct hstate *h, int nid) > return 1; > } > > +/* Initialize [start_page:end_page_number] tail struct pages of a hugepage */ > +static void __init hugetlb_folio_init_tail_vmemmap(struct folio *folio, > + unsigned long start_page_number, > + unsigned long end_page_number) > +{ > + enum zone_type zone = zone_idx(folio_zone(folio)); > + int nid = folio_nid(folio); > + unsigned long head_pfn = folio_pfn(folio); > + unsigned long pfn, end_pfn = head_pfn + end_page_number; > + > + for (pfn = head_pfn + start_page_number; pfn < end_pfn; pfn++) { > + struct page *page = pfn_to_page(pfn); > + > + __init_single_page(page, pfn, zone, nid); > + prep_compound_tail((struct page *)folio, pfn - head_pfn); > + set_page_count(page, 0); > + } > +} > + > +static void __init hugetlb_folio_init_vmemmap(struct folio *folio, struct hstate *h, > + unsigned long nr_pages) > +{ > + int ret; > + > + /* Prepare folio head */ > + __folio_clear_reserved(folio); > + __folio_set_head(folio); > + ret = page_ref_freeze(&folio->page, 1); > + VM_BUG_ON(!ret); In the current code, we print a warning and free the associated pages to buddy if we ever experience an increased ref count. The routine hugetlb_folio_init_tail_vmemmap does not check for this. I do not believe speculative/temporary ref counts this early in the boot process are possible. It would be great to get input from someone else. When I wrote the existing code, it was fairly easy to WARN and continue if we encountered an increased ref count. Things would be bit more complicated here. So, it may not be worth the effort.
> On Sep 8, 2023, at 02:37, Mike Kravetz <mike.kravetz@oracle.com> wrote: > > On 09/06/23 12:26, Usama Arif wrote: >> The new boot flow when it comes to initialization of gigantic pages >> is as follows: >> - At boot time, for a gigantic page during __alloc_bootmem_hugepage, >> the region after the first struct page is marked as noinit. >> - This results in only the first struct page to be >> initialized in reserve_bootmem_region. As the tail struct pages are >> not initialized at this point, there can be a significant saving >> in boot time if HVO succeeds later on. >> - Later on in the boot, the head page is prepped and the first >> HUGETLB_VMEMMAP_RESERVE_SIZE / sizeof(struct page) - 1 tail struct pages >> are initialized. >> - HVO is attempted. If it is not successful, then the rest of the >> tail struct pages are initialized. If it is successful, no more >> tail struct pages need to be initialized saving significant boot time. >> >> Signed-off-by: Usama Arif <usama.arif@bytedance.com> >> --- >> mm/hugetlb.c | 61 +++++++++++++++++++++++++++++++++++++------- >> mm/hugetlb_vmemmap.c | 2 +- >> mm/hugetlb_vmemmap.h | 9 ++++--- >> mm/internal.h | 3 +++ >> mm/mm_init.c | 2 +- >> 5 files changed, 62 insertions(+), 15 deletions(-) > > As mentioned, in general this looks good. One small point below. > >> diff --git a/mm/hugetlb.c b/mm/hugetlb.c >> index c32ca241df4b..540e0386514e 100644 >> --- a/mm/hugetlb.c >> +++ b/mm/hugetlb.c >> @@ -3169,6 +3169,15 @@ int __alloc_bootmem_huge_page(struct hstate *h, int nid) >> } >> >> found: >> + >> + /* >> + * Only initialize the head struct page in memmap_init_reserved_pages, >> + * rest of the struct pages will be initialized by the HugeTLB subsystem itself. >> + * The head struct page is used to get folio information by the HugeTLB >> + * subsystem like zone id and node id. >> + */ >> + memblock_reserved_mark_noinit(virt_to_phys((void *)m + PAGE_SIZE), >> + huge_page_size(h) - PAGE_SIZE); >> /* Put them into a private list first because mem_map is not up yet */ >> INIT_LIST_HEAD(&m->list); >> list_add(&m->list, &huge_boot_pages); >> @@ -3176,6 +3185,40 @@ int __alloc_bootmem_huge_page(struct hstate *h, int nid) >> return 1; >> } >> >> +/* Initialize [start_page:end_page_number] tail struct pages of a hugepage */ >> +static void __init hugetlb_folio_init_tail_vmemmap(struct folio *folio, >> + unsigned long start_page_number, >> + unsigned long end_page_number) >> +{ >> + enum zone_type zone = zone_idx(folio_zone(folio)); >> + int nid = folio_nid(folio); >> + unsigned long head_pfn = folio_pfn(folio); >> + unsigned long pfn, end_pfn = head_pfn + end_page_number; >> + >> + for (pfn = head_pfn + start_page_number; pfn < end_pfn; pfn++) { >> + struct page *page = pfn_to_page(pfn); >> + >> + __init_single_page(page, pfn, zone, nid); >> + prep_compound_tail((struct page *)folio, pfn - head_pfn); >> + set_page_count(page, 0); >> + } >> +} >> + >> +static void __init hugetlb_folio_init_vmemmap(struct folio *folio, struct hstate *h, >> + unsigned long nr_pages) >> +{ >> + int ret; >> + >> + /* Prepare folio head */ >> + __folio_clear_reserved(folio); >> + __folio_set_head(folio); >> + ret = page_ref_freeze(&folio->page, 1); >> + VM_BUG_ON(!ret); > > In the current code, we print a warning and free the associated pages to > buddy if we ever experience an increased ref count. The routine > hugetlb_folio_init_tail_vmemmap does not check for this. > > I do not believe speculative/temporary ref counts this early in the boot > process are possible. It would be great to get input from someone else. Yes, it is a very early stage and other tail struct pages haven't been initialized yet, anyone should not reference them. It it the same case as CONFIG_DEFERRED_STRUCT_PAGE_INIT enabled. > > When I wrote the existing code, it was fairly easy to WARN and continue > if we encountered an increased ref count. Things would be bit more In your case, I think it is not in the boot process, right? > complicated here. So, it may not be worth the effort. Agree. Note that tail struct pages are not initialized here, if we want to handle head page, how to handle tail pages? It really cannot resolved. We should make the same assumption as CONFIG_DEFERRED_STRUCT_PAGE_INIT that anyone should not reference those pages. Thanks.
On 09/08/23 10:39, Muchun Song wrote: > > > > On Sep 8, 2023, at 02:37, Mike Kravetz <mike.kravetz@oracle.com> wrote: > > > > On 09/06/23 12:26, Usama Arif wrote: > >> The new boot flow when it comes to initialization of gigantic pages > >> is as follows: > >> - At boot time, for a gigantic page during __alloc_bootmem_hugepage, > >> the region after the first struct page is marked as noinit. > >> - This results in only the first struct page to be > >> initialized in reserve_bootmem_region. As the tail struct pages are > >> not initialized at this point, there can be a significant saving > >> in boot time if HVO succeeds later on. > >> - Later on in the boot, the head page is prepped and the first > >> HUGETLB_VMEMMAP_RESERVE_SIZE / sizeof(struct page) - 1 tail struct pages > >> are initialized. > >> - HVO is attempted. If it is not successful, then the rest of the > >> tail struct pages are initialized. If it is successful, no more > >> tail struct pages need to be initialized saving significant boot time. > >> > >> Signed-off-by: Usama Arif <usama.arif@bytedance.com> > >> --- > >> mm/hugetlb.c | 61 +++++++++++++++++++++++++++++++++++++------- > >> mm/hugetlb_vmemmap.c | 2 +- > >> mm/hugetlb_vmemmap.h | 9 ++++--- > >> mm/internal.h | 3 +++ > >> mm/mm_init.c | 2 +- > >> 5 files changed, 62 insertions(+), 15 deletions(-) > > > > As mentioned, in general this looks good. One small point below. > > > >> diff --git a/mm/hugetlb.c b/mm/hugetlb.c > >> index c32ca241df4b..540e0386514e 100644 > >> --- a/mm/hugetlb.c > >> +++ b/mm/hugetlb.c > >> @@ -3169,6 +3169,15 @@ int __alloc_bootmem_huge_page(struct hstate *h, int nid) > >> } > >> > >> found: > >> + > >> + /* > >> + * Only initialize the head struct page in memmap_init_reserved_pages, > >> + * rest of the struct pages will be initialized by the HugeTLB subsystem itself. > >> + * The head struct page is used to get folio information by the HugeTLB > >> + * subsystem like zone id and node id. > >> + */ > >> + memblock_reserved_mark_noinit(virt_to_phys((void *)m + PAGE_SIZE), > >> + huge_page_size(h) - PAGE_SIZE); > >> /* Put them into a private list first because mem_map is not up yet */ > >> INIT_LIST_HEAD(&m->list); > >> list_add(&m->list, &huge_boot_pages); > >> @@ -3176,6 +3185,40 @@ int __alloc_bootmem_huge_page(struct hstate *h, int nid) > >> return 1; > >> } > >> > >> +/* Initialize [start_page:end_page_number] tail struct pages of a hugepage */ > >> +static void __init hugetlb_folio_init_tail_vmemmap(struct folio *folio, > >> + unsigned long start_page_number, > >> + unsigned long end_page_number) > >> +{ > >> + enum zone_type zone = zone_idx(folio_zone(folio)); > >> + int nid = folio_nid(folio); > >> + unsigned long head_pfn = folio_pfn(folio); > >> + unsigned long pfn, end_pfn = head_pfn + end_page_number; > >> + > >> + for (pfn = head_pfn + start_page_number; pfn < end_pfn; pfn++) { > >> + struct page *page = pfn_to_page(pfn); > >> + > >> + __init_single_page(page, pfn, zone, nid); > >> + prep_compound_tail((struct page *)folio, pfn - head_pfn); > >> + set_page_count(page, 0); > >> + } > >> +} > >> + > >> +static void __init hugetlb_folio_init_vmemmap(struct folio *folio, struct hstate *h, > >> + unsigned long nr_pages) > >> +{ > >> + int ret; > >> + > >> + /* Prepare folio head */ > >> + __folio_clear_reserved(folio); > >> + __folio_set_head(folio); > >> + ret = page_ref_freeze(&folio->page, 1); > >> + VM_BUG_ON(!ret); > > > > In the current code, we print a warning and free the associated pages to > > buddy if we ever experience an increased ref count. The routine > > hugetlb_folio_init_tail_vmemmap does not check for this. > > > > I do not believe speculative/temporary ref counts this early in the boot > > process are possible. It would be great to get input from someone else. > > Yes, it is a very early stage and other tail struct pages haven't been > initialized yet, anyone should not reference them. It it the same case > as CONFIG_DEFERRED_STRUCT_PAGE_INIT enabled. > > > > > When I wrote the existing code, it was fairly easy to WARN and continue > > if we encountered an increased ref count. Things would be bit more > > In your case, I think it is not in the boot process, right? They were calls in the same routine: gather_bootmem_prealloc(). > > complicated here. So, it may not be worth the effort. > > Agree. Note that tail struct pages are not initialized here, if we want to > handle head page, how to handle tail pages? It really cannot resolved. > We should make the same assumption as CONFIG_DEFERRED_STRUCT_PAGE_INIT > that anyone should not reference those pages. Agree that speculative refs should not happen this early. How about making the following changes? - Instead of set_page_count() in hugetlb_folio_init_tail_vmemmap, do a page_ref_freeze and VM_BUG_ON if not ref_count != 1. - In the commit message, mention 'The WARN_ON for increased ref count in gather_bootmem_prealloc was changed to a VM_BUG_ON. This is OK as there should be no speculative references this early in boot process. The VM_BUG_ON's are there just in case such code is introduced.'
On 08/09/2023 19:29, Mike Kravetz wrote: > On 09/08/23 10:39, Muchun Song wrote: >> >> >>> On Sep 8, 2023, at 02:37, Mike Kravetz <mike.kravetz@oracle.com> wrote: >>> >>> On 09/06/23 12:26, Usama Arif wrote: >>>> The new boot flow when it comes to initialization of gigantic pages >>>> is as follows: >>>> - At boot time, for a gigantic page during __alloc_bootmem_hugepage, >>>> the region after the first struct page is marked as noinit. >>>> - This results in only the first struct page to be >>>> initialized in reserve_bootmem_region. As the tail struct pages are >>>> not initialized at this point, there can be a significant saving >>>> in boot time if HVO succeeds later on. >>>> - Later on in the boot, the head page is prepped and the first >>>> HUGETLB_VMEMMAP_RESERVE_SIZE / sizeof(struct page) - 1 tail struct pages >>>> are initialized. >>>> - HVO is attempted. If it is not successful, then the rest of the >>>> tail struct pages are initialized. If it is successful, no more >>>> tail struct pages need to be initialized saving significant boot time. >>>> >>>> Signed-off-by: Usama Arif <usama.arif@bytedance.com> >>>> --- >>>> mm/hugetlb.c | 61 +++++++++++++++++++++++++++++++++++++------- >>>> mm/hugetlb_vmemmap.c | 2 +- >>>> mm/hugetlb_vmemmap.h | 9 ++++--- >>>> mm/internal.h | 3 +++ >>>> mm/mm_init.c | 2 +- >>>> 5 files changed, 62 insertions(+), 15 deletions(-) >>> >>> As mentioned, in general this looks good. One small point below. >>> >>>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c >>>> index c32ca241df4b..540e0386514e 100644 >>>> --- a/mm/hugetlb.c >>>> +++ b/mm/hugetlb.c >>>> @@ -3169,6 +3169,15 @@ int __alloc_bootmem_huge_page(struct hstate *h, int nid) >>>> } >>>> >>>> found: >>>> + >>>> + /* >>>> + * Only initialize the head struct page in memmap_init_reserved_pages, >>>> + * rest of the struct pages will be initialized by the HugeTLB subsystem itself. >>>> + * The head struct page is used to get folio information by the HugeTLB >>>> + * subsystem like zone id and node id. >>>> + */ >>>> + memblock_reserved_mark_noinit(virt_to_phys((void *)m + PAGE_SIZE), >>>> + huge_page_size(h) - PAGE_SIZE); >>>> /* Put them into a private list first because mem_map is not up yet */ >>>> INIT_LIST_HEAD(&m->list); >>>> list_add(&m->list, &huge_boot_pages); >>>> @@ -3176,6 +3185,40 @@ int __alloc_bootmem_huge_page(struct hstate *h, int nid) >>>> return 1; >>>> } >>>> >>>> +/* Initialize [start_page:end_page_number] tail struct pages of a hugepage */ >>>> +static void __init hugetlb_folio_init_tail_vmemmap(struct folio *folio, >>>> + unsigned long start_page_number, >>>> + unsigned long end_page_number) >>>> +{ >>>> + enum zone_type zone = zone_idx(folio_zone(folio)); >>>> + int nid = folio_nid(folio); >>>> + unsigned long head_pfn = folio_pfn(folio); >>>> + unsigned long pfn, end_pfn = head_pfn + end_page_number; >>>> + >>>> + for (pfn = head_pfn + start_page_number; pfn < end_pfn; pfn++) { >>>> + struct page *page = pfn_to_page(pfn); >>>> + >>>> + __init_single_page(page, pfn, zone, nid); >>>> + prep_compound_tail((struct page *)folio, pfn - head_pfn); >>>> + set_page_count(page, 0); >>>> + } >>>> +} >>>> + >>>> +static void __init hugetlb_folio_init_vmemmap(struct folio *folio, struct hstate *h, >>>> + unsigned long nr_pages) >>>> +{ >>>> + int ret; >>>> + >>>> + /* Prepare folio head */ >>>> + __folio_clear_reserved(folio); >>>> + __folio_set_head(folio); >>>> + ret = page_ref_freeze(&folio->page, 1); >>>> + VM_BUG_ON(!ret); >>> >>> In the current code, we print a warning and free the associated pages to >>> buddy if we ever experience an increased ref count. The routine >>> hugetlb_folio_init_tail_vmemmap does not check for this. >>> >>> I do not believe speculative/temporary ref counts this early in the boot >>> process are possible. It would be great to get input from someone else. >> >> Yes, it is a very early stage and other tail struct pages haven't been >> initialized yet, anyone should not reference them. It it the same case >> as CONFIG_DEFERRED_STRUCT_PAGE_INIT enabled. >> >>> >>> When I wrote the existing code, it was fairly easy to WARN and continue >>> if we encountered an increased ref count. Things would be bit more >> >> In your case, I think it is not in the boot process, right? > > They were calls in the same routine: gather_bootmem_prealloc(). > >>> complicated here. So, it may not be worth the effort. >> >> Agree. Note that tail struct pages are not initialized here, if we want to >> handle head page, how to handle tail pages? It really cannot resolved. >> We should make the same assumption as CONFIG_DEFERRED_STRUCT_PAGE_INIT >> that anyone should not reference those pages. > > Agree that speculative refs should not happen this early. How about making > the following changes? > - Instead of set_page_count() in hugetlb_folio_init_tail_vmemmap, do a > page_ref_freeze and VM_BUG_ON if not ref_count != 1. > - In the commit message, mention 'The WARN_ON for increased ref count in > gather_bootmem_prealloc was changed to a VM_BUG_ON. This is OK as > there should be no speculative references this early in boot process. > The VM_BUG_ON's are there just in case such code is introduced.' Sounds good, although its not possible for the refcnt to not be 1 as there isnt anything that happens between __init_single_page and setting/freezing refcnt to 0. I will include the below diff in the next revision with the explanation in commit message as suggested. diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 540e0386514e..ed37c6e4e952 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -3194,13 +3194,15 @@ static void __init hugetlb_folio_init_tail_vmemmap(struct folio *folio, int nid = folio_nid(folio); unsigned long head_pfn = folio_pfn(folio); unsigned long pfn, end_pfn = head_pfn + end_page_number; + int ret; for (pfn = head_pfn + start_page_number; pfn < end_pfn; pfn++) { struct page *page = pfn_to_page(pfn); __init_single_page(page, pfn, zone, nid); prep_compound_tail((struct page *)folio, pfn - head_pfn); - set_page_count(page, 0); + ret = page_ref_freeze(page, 1); + VM_BUG_ON(!ret); } }
diff --git a/mm/hugetlb.c b/mm/hugetlb.c index c32ca241df4b..540e0386514e 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -3169,6 +3169,15 @@ int __alloc_bootmem_huge_page(struct hstate *h, int nid) } found: + + /* + * Only initialize the head struct page in memmap_init_reserved_pages, + * rest of the struct pages will be initialized by the HugeTLB subsystem itself. + * The head struct page is used to get folio information by the HugeTLB + * subsystem like zone id and node id. + */ + memblock_reserved_mark_noinit(virt_to_phys((void *)m + PAGE_SIZE), + huge_page_size(h) - PAGE_SIZE); /* Put them into a private list first because mem_map is not up yet */ INIT_LIST_HEAD(&m->list); list_add(&m->list, &huge_boot_pages); @@ -3176,6 +3185,40 @@ int __alloc_bootmem_huge_page(struct hstate *h, int nid) return 1; } +/* Initialize [start_page:end_page_number] tail struct pages of a hugepage */ +static void __init hugetlb_folio_init_tail_vmemmap(struct folio *folio, + unsigned long start_page_number, + unsigned long end_page_number) +{ + enum zone_type zone = zone_idx(folio_zone(folio)); + int nid = folio_nid(folio); + unsigned long head_pfn = folio_pfn(folio); + unsigned long pfn, end_pfn = head_pfn + end_page_number; + + for (pfn = head_pfn + start_page_number; pfn < end_pfn; pfn++) { + struct page *page = pfn_to_page(pfn); + + __init_single_page(page, pfn, zone, nid); + prep_compound_tail((struct page *)folio, pfn - head_pfn); + set_page_count(page, 0); + } +} + +static void __init hugetlb_folio_init_vmemmap(struct folio *folio, struct hstate *h, + unsigned long nr_pages) +{ + int ret; + + /* Prepare folio head */ + __folio_clear_reserved(folio); + __folio_set_head(folio); + ret = page_ref_freeze(&folio->page, 1); + VM_BUG_ON(!ret); + /* Initialize the necessary tail struct pages */ + hugetlb_folio_init_tail_vmemmap(folio, 1, nr_pages); + prep_compound_head((struct page *)folio, huge_page_order(h)); +} + /* * Put bootmem huge pages into the standard lists after mem_map is up. * Note: This only applies to gigantic (order > MAX_ORDER) pages. @@ -3186,19 +3229,19 @@ static void __init gather_bootmem_prealloc(void) list_for_each_entry(m, &huge_boot_pages, list) { struct page *page = virt_to_page(m); - struct folio *folio = page_folio(page); + struct folio *folio = (void *)page; struct hstate *h = m->hstate; VM_BUG_ON(!hstate_is_gigantic(h)); WARN_ON(folio_ref_count(folio) != 1); - if (prep_compound_gigantic_folio(folio, huge_page_order(h))) { - WARN_ON(folio_test_reserved(folio)); - prep_new_hugetlb_folio(h, folio, folio_nid(folio)); - free_huge_folio(folio); /* add to the hugepage allocator */ - } else { - /* VERY unlikely inflated ref count on a tail page */ - free_gigantic_folio(folio, huge_page_order(h)); - } + + hugetlb_folio_init_vmemmap(folio, h, HUGETLB_VMEMMAP_RESERVE_PAGES); + prep_new_hugetlb_folio(h, folio, folio_nid(folio)); + /* If HVO fails, initialize all tail struct pages */ + if (!HPageVmemmapOptimized(&folio->page)) + hugetlb_folio_init_tail_vmemmap(folio, HUGETLB_VMEMMAP_RESERVE_PAGES, + pages_per_huge_page(h)); + free_huge_folio(folio); /* add to the hugepage allocator */ /* * We need to restore the 'stolen' pages to totalram_pages diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c index 3cdb38d87a95..772a877918d7 100644 --- a/mm/hugetlb_vmemmap.c +++ b/mm/hugetlb_vmemmap.c @@ -589,7 +589,7 @@ static int __init hugetlb_vmemmap_init(void) const struct hstate *h; /* HUGETLB_VMEMMAP_RESERVE_SIZE should cover all used struct pages */ - BUILD_BUG_ON(__NR_USED_SUBPAGE * sizeof(struct page) > HUGETLB_VMEMMAP_RESERVE_SIZE); + BUILD_BUG_ON(__NR_USED_SUBPAGE > HUGETLB_VMEMMAP_RESERVE_PAGES); for_each_hstate(h) { if (hugetlb_vmemmap_optimizable(h)) { diff --git a/mm/hugetlb_vmemmap.h b/mm/hugetlb_vmemmap.h index 25bd0e002431..4573899855d7 100644 --- a/mm/hugetlb_vmemmap.h +++ b/mm/hugetlb_vmemmap.h @@ -10,15 +10,16 @@ #define _LINUX_HUGETLB_VMEMMAP_H #include <linux/hugetlb.h> -#ifdef CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP -int hugetlb_vmemmap_restore(const struct hstate *h, struct page *head); -void hugetlb_vmemmap_optimize(const struct hstate *h, struct page *head); - /* * Reserve one vmemmap page, all vmemmap addresses are mapped to it. See * Documentation/vm/vmemmap_dedup.rst. */ #define HUGETLB_VMEMMAP_RESERVE_SIZE PAGE_SIZE +#define HUGETLB_VMEMMAP_RESERVE_PAGES (HUGETLB_VMEMMAP_RESERVE_SIZE / sizeof(struct page)) + +#ifdef CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP +int hugetlb_vmemmap_restore(const struct hstate *h, struct page *head); +void hugetlb_vmemmap_optimize(const struct hstate *h, struct page *head); static inline unsigned int hugetlb_vmemmap_size(const struct hstate *h) { diff --git a/mm/internal.h b/mm/internal.h index d1d4bf4e63c0..d74061aa6de7 100644 --- a/mm/internal.h +++ b/mm/internal.h @@ -1154,4 +1154,7 @@ struct vma_prepare { struct vm_area_struct *remove; struct vm_area_struct *remove2; }; + +void __meminit __init_single_page(struct page *page, unsigned long pfn, + unsigned long zone, int nid); #endif /* __MM_INTERNAL_H */ diff --git a/mm/mm_init.c b/mm/mm_init.c index 50f2f34745af..fed4370b02e1 100644 --- a/mm/mm_init.c +++ b/mm/mm_init.c @@ -555,7 +555,7 @@ static void __init find_zone_movable_pfns_for_nodes(void) node_states[N_MEMORY] = saved_node_state; } -static void __meminit __init_single_page(struct page *page, unsigned long pfn, +void __meminit __init_single_page(struct page *page, unsigned long pfn, unsigned long zone, int nid) { mm_zero_struct_page(page);
The new boot flow when it comes to initialization of gigantic pages is as follows: - At boot time, for a gigantic page during __alloc_bootmem_hugepage, the region after the first struct page is marked as noinit. - This results in only the first struct page to be initialized in reserve_bootmem_region. As the tail struct pages are not initialized at this point, there can be a significant saving in boot time if HVO succeeds later on. - Later on in the boot, the head page is prepped and the first HUGETLB_VMEMMAP_RESERVE_SIZE / sizeof(struct page) - 1 tail struct pages are initialized. - HVO is attempted. If it is not successful, then the rest of the tail struct pages are initialized. If it is successful, no more tail struct pages need to be initialized saving significant boot time. Signed-off-by: Usama Arif <usama.arif@bytedance.com> --- mm/hugetlb.c | 61 +++++++++++++++++++++++++++++++++++++------- mm/hugetlb_vmemmap.c | 2 +- mm/hugetlb_vmemmap.h | 9 ++++--- mm/internal.h | 3 +++ mm/mm_init.c | 2 +- 5 files changed, 62 insertions(+), 15 deletions(-)