linux-kernel - Re: [External] Re: [v4 4/4] mm: hugetlb: Skip initialization of gigantic tail struct pages if freed by HVO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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