Re: + mm-hugetlb-make-alloc_gigantic_page-available-for-general-use.patch added to -mm tree

[Matthew Wilcox <willy@infradead.org>]

On Tue, Oct 15, 2019 at 03:00:49PM +0530, Anshuman Khandual wrote:
> On 10/15/2019 01:59 AM, Matthew Wilcox wrote:
> > On Mon, Oct 14, 2019 at 02:17:30PM +0200, Michal Hocko wrote:
> >> On Fri 11-10-19 13:29:32, Andrew Morton wrote:
> >>> alloc_gigantic_page() implements an allocation method where it scans over
> >>> various zones looking for a large contiguous memory block which could not
> >>> have been allocated through the buddy allocator.  A subsequent patch which
> >>> tests arch page table helpers needs such a method to allocate PUD_SIZE
> >>> sized memory block.  In the future such methods might have other use cases
> >>> as well.  So alloc_gigantic_page() has been split carving out actual
> >>> memory allocation method and made available via new
> >>> alloc_gigantic_page_order().
> >>
> >> You are exporting a helper used for hugetlb internally. Is this really
> >> what is needed? I haven't followed this patchset but don't you simply
> >> need a generic 1GB allocator? If yes then you should be looking at
> >> alloc_contig_range.
> > 
> > He actually doesn't need to allocate any memory at all.  All he needs is
> > the address of a valid contiguous PUD-sized chunk of memory.
> > 
> 
> We had already discussed about the benefits of allocated memory over
> synthetic pfn potentially derived from a kernel text symbol. More
> over we are not adding any new helper or new code for this purpose,
> but instead just trying to reuse code which is already present.

Yes, and I'm pretty sure you're just wrong.  But I don't know that you're
wrong for all architectures.  Re-reading that, I'm still not sure you
understood what I was suggesting, so I'll say it again differently.

Look up a kernel symbol, something like kernel_init().  This will
have a virtual address upon which it is safe to call virt_to_pfn().
Let's presume it's in PFN 0x12345678.  Use 0x12345678 as the PFN for
your PTE level tests.

Then clear the bottom (eg) 9 bits from it and use 0x1234400 for your PMD
level tests.  Then clear the bottom 18 bits from it and use 0x12300000
for your PUD level tests.

I don't think it matters whether there's physical memory at PFN 0x12300000
or not.  The various p?d_* functions should work as long as the PFN is
in some plausible range.

I gave up arguing because you seemed uninterested in this approach,
but now that Michal is pointing out that your approach is all wrong,
maybe you'll listen.