Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0
Subject: Re: [v5 4/4] mm: hugetlb: Skip initialization of gigantic tail struct
 pages if freed by HVO
From:   Muchun Song <muchun.song@linux.dev>
In-Reply-To: <20230913105401.519709-5-usama.arif@bytedance.com>
Date:   Thu, 14 Sep 2023 10:45:38 +0800
Cc:     Linux-MM <linux-mm@kvack.org>,
        Mike Kravetz <mike.kravetz@oracle.com>,
        "Mike Rapoport (IBM)" <rppt@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Muchun Song <songmuchun@bytedance.com>,
        fam.zheng@bytedance.com, liangma@liangbit.com,
        punit.agrawal@bytedance.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <53B87FC1-5854-4E54-B28F-C13D3EA662C3@linux.dev>
References: <20230913105401.519709-1-usama.arif@bytedance.com>
 <20230913105401.519709-5-usama.arif@bytedance.com>
To:     Usama Arif <usama.arif@bytedance.com>
Precedence: bulk


> On Sep 13, 2023, at 18:54, Usama Arif <usama.arif@bytedance.com> =
wrote:
>=20
> 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.
>=20
> 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.
>=20
> Signed-off-by: Usama Arif <usama.arif@bytedance.com>

Reviewed-by: Muchun Song <songmuchun@bytedance.com>

Thanks for your work.