Re: [PATCH V6 1/2] mm/page_alloc: Make alloc_gigantic_page() available for general use

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue 15-10-19 14:51:41, Anshuman Khandual wrote:
[...]
> +/**
> + * alloc_gigantic_page_order() -- tries to allocate given order of pages
> + * @order:	allocation order (greater than MAX_ORDER)
> + * @gfp_mask:	GFP mask to use during compaction
> + * @nid:	allocation node
> + * @nodemask:	allocation nodemask
> + *
> + * This routine is an wrapper around alloc_contig_range() which scans over
> + * all zones on an applicable zonelist to find a contiguous pfn range which
> + * can the be allocated with alloc_contig_range(). This routine is intended
> + * to be used for allocations greater than MAX_ORDER.
> + *
> + * Return: page on success or NULL on failure. On success a memory block
> + * of 'order' starting with 'page' has been allocated successfully. Memory
> + * allocated here needs to be freed with free_contig_range().
> + */
> +struct page *alloc_gigantic_page_order(unsigned int order, gfp_t gfp_mask,
> +				       int nid, nodemask_t *nodemask)

One of the objections when Mike has proposed a similar thing last year
was that the interface shouldn't be order bases
http://lkml.kernel.org/r/20180423000943.GO17484@xxxxxxxxxxxxxx

Order based API makes sense for the buddy allocator but why should we
restrict sizes like that for an allocator that is capable to allocate
arbitrary page sized requests?
-- 
Michal Hocko
SUSE Labs

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-snps-arc



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux