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
