On Tue, Aug 18, 2020 at 9:22 AM David Hildenbrand <david@xxxxxxxxxx> 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. 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 > >
