On Mon, Aug 25, 2025 at 02:48:58PM +0200, David Hildenbrand wrote: > On 23.08.25 10:59, Mike Rapoport wrote: > > On Fri, Aug 22, 2025 at 08:24:31AM +0200, David Hildenbrand wrote: > > > On 22.08.25 06:09, Mika Penttilä wrote: > > > > > > > > On 8/21/25 23:06, David Hildenbrand wrote: > > > > > > > > > All pages were already initialized and set to PageReserved() with a > > > > > refcount of 1 by MM init code. > > > > > > > > Just to be sure, how is this working with MEMBLOCK_RSRV_NOINIT, where > > > > MM is supposed not to > > > > initialize struct pages? > > > > > > Excellent point, I did not know about that one. > > > > > > Spotting that we don't do the same for the head page made me assume that > > > it's just a misuse of __init_single_page(). > > > > > > But the nasty thing is that we use memblock_reserved_mark_noinit() to only > > > mark the tail pages ... > > > > And even nastier thing is that when CONFIG_DEFERRED_STRUCT_PAGE_INIT is > > disabled struct pages are initialized regardless of > > memblock_reserved_mark_noinit(). > > > > I think this patch should go in before your updates: > > Shouldn't we fix this in memblock code? > > Hacking around that in the memblock_reserved_mark_noinit() user sound wrong > -- and nothing in the doc of memblock_reserved_mark_noinit() spells that > behavior out.
We can surely update the docs, but unfortunately I don't see how to avoid hacking around it in hugetlb. Since it's used to optimise HVO even further to the point hugetlb open codes memmap initialization, I think it's fair that it should deal with all possible configurations. > -- > Cheers > > David / dhildenb > > -- Sincerely yours, Mike.
