On Tue, Aug 18, 2020 at 06:22:10PM +0200, David Hildenbrand wrote: > On 18.08.20 17:58, Matthew Wilcox wrote: > > On Tue, Aug 18, 2020 at 08:15:43AM -0700, Minchan Kim wrote: > >> 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.
