[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230906215927.GE3612@monkey>
Date: Wed, 6 Sep 2023 14:59:27 -0700
From: Mike Kravetz <mike.kravetz@...cle.com>
To: Usama Arif <usama.arif@...edance.com>
Cc: linux-mm@...ck.org, muchun.song@...ux.dev, rppt@...nel.org,
linux-kernel@...r.kernel.org, songmuchun@...edance.com,
fam.zheng@...edance.com, liangma@...ngbit.com,
punit.agrawal@...edance.com
Subject: Re: [External] Re: [v4 4/4] mm: hugetlb: Skip initialization of
gigantic tail struct pages if freed by HVO
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.
--
Mike Kravetz
Powered by blists - more mailing lists