On Tue, Aug 18, 2020 at 9:22 AM David Hildenbrand [off-list ref] 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.
Make sense to me. There are plenty such optimizations in mm, i.e.
light async migration vs sync migration.
And, it looks Minchan could accept allocation failure (return less
than "elem" pages), then the user could just retry.
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()).
Yes, it might not end up as fast as this big hack (sorry) here, but as
Nicholas correctly said, it's not our motivation to implement and
maintain such complexity just to squeeze the last milliseconds out of an
allocation path for "broken devices".
I absolutely dislike pushing this very specific allocation policy down
to the core range allocator. It's already makes my head spin every time
I look at it in detail.
--
Thanks,
David / dhildenb