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. https://lore.kernel.org/linux-mm/1565335998-22553-1-git-send-email-anshuman.khandual@xxxxxxx/T/
