On 10/02/23 11:57, Konrad Dybcio wrote: > > > On 9/29/23 22:57, Mike Kravetz wrote: > > On 09/27/23 13:26, Konrad Dybcio wrote: > > > > > > > > > On 26.09.2023 01:48, Mike Kravetz wrote: > > > > Allocation of a hugetlb page for the hugetlb pool is done by the routine > > > > alloc_pool_huge_page. This routine will allocate contiguous pages from > > > > a low level allocator, prep the pages for usage as a hugetlb page and > > > > then add the resulting hugetlb page to the pool. > > > > > > > > In the 'prep' stage, optional vmemmap optimization is done. For > > > > performance reasons we want to perform vmemmap optimization on multiple > > > > hugetlb pages at once. To do this, restructure the hugetlb pool > > > > allocation code such that vmemmap optimization can be isolated and later > > > > batched. > > > > > > > > The code to allocate hugetlb pages from bootmem was also modified to > > > > allow batching. > > > > > > > > No functional changes, only code restructure. > > > > > > > > Signed-off-by: Mike Kravetz <mike.kravetz@xxxxxxxxxx> > > > > Reviewed-by: Muchun Song <songmuchun@xxxxxxxxxxxxx> > > > > --- > > > Hi, looks like this patch prevents today's next from booting > > > on at least one Qualcomm ARM64 platform. Reverting it makes > > > the device boot again. > > > > Can you share the config used and any other specific information such as > > kernel command line. > Later this week. As mentioned, I have been unable to reproduce on arm64 platforms I can access. I have tried various config and boot options. While doing so, I came across one issue impacting kernels compiled without CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP defined. This is not something that would prevent booting. I will send out an updated version series in the hope that any other issues may be discovered. -- Mike Kravetz
