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]
Message-ID: <20230906181016.GA3612@monkey>
Date:   Wed, 6 Sep 2023 11:10:16 -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: [v4 4/4] mm: hugetlb: Skip initialization of gigantic tail
 struct pages if freed by HVO

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).

-- 
Mike Kravetz

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ