[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231006223512.GC3861@monkey>
Date: Fri, 6 Oct 2023 15:35:12 -0700
From: Mike Kravetz <mike.kravetz@...cle.com>
To: Konrad Dybcio <konrad.dybcio@...aro.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Anshuman Khandual <anshuman.khandual@....com>,
Xiongchun Duan <duanxiongchun@...edance.com>,
Barry Song <21cnbao@...il.com>,
David Rientjes <rientjes@...gle.com>,
Miaohe Lin <linmiaohe@...wei.com>,
Matthew Wilcox <willy@...radead.org>, linux-mm@...ck.org,
Naoya Horiguchi <naoya.horiguchi@...ux.dev>,
Joao Martins <joao.m.martins@...cle.com>,
David Hildenbrand <david@...hat.com>,
Michal Hocko <mhocko@...e.com>,
Oscar Salvador <osalvador@...e.de>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 2/8] hugetlb: restructure pool allocations
On 10/06/23 23:39, Konrad Dybcio wrote:
> On 6.10.2023 05:08, Mike Kravetz wrote:
> > 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@...cle.com>
> >>>>> Reviewed-by: Muchun Song <songmuchun@...edance.com>
> >>>>> ---
> >>>> 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.
> I'm pushing the "later this week" by answering near end of calendar
> day, Friday, but it seems like this patch in v7 still prevents the
> device from booting..
>
> You can find my defconfig at the link below.
>
> https://gist.github.com/konradybcio/d865f8dc9b12a98ba3875ec5a9aac42e
>
Thanks!
I assume there is no further information such as any console output?
Did any of you other arm64 platforms have this issue?
Just trying to get as much information as possible to get to root cause.
--
Mike Kravetz
Powered by blists - more mailing lists