On Tue, Aug 18, 2020 at 06:22:10PM +0200, David Hildenbrand wrote:
On 18.08.20 17:58, Matthew Wilcox wrote:
quoted
On Tue, Aug 18, 2020 at 08:15:43AM -0700, Minchan Kim wrote:
quoted
I understand pfn stuff in the API is not pretty but the concept of idea
makes sense to me in that go though the *migratable area* and get possible
order pages with hard effort. It looks like GFP_NORETRY version for
kmem_cache_alloc_bulk.
How about this?
int cma_alloc(struct cma *cma, int order, unsigned int nr_elem, struct page **pages);
I think that makes a lot more sense as an API. Although I think you want
int cma_bulk_alloc(struct cma *cma, unsigned order, unsigned nr_elem,
struct page **pages);
Right, and I would start with a very simple implementation that does not
mess with alloc_contig_range() (meaning: modify it).
I'd then much rather want to see simple tweaks to alloc_contig_range()
to improve the situation. E.g., some kind of "fail fast" flag that let's
the caller specify to skip some draining (or do it manually in cma
before a bulk allocation) and rather fail fast than really trying to
allocate the range whatever it costs.
There are multiple optimizations you can play with then (start with big
granularity and split, move to smaller granularity on demand, etc., all
nicely wrapped in cma_bulk_alloc()).
Okay, let me hide the detail inside cma_bulk_alloc as much as possible.
Anyway, at least we need to pass some flag to indicate "fail fast"
in alloc_contig_range. Maybe __GFP_NORETRY could carry on the indication.
Thanks for the review.