Re: [PATCH v2] mm: cma: indefinitely retry allocations in cma_alloc

[Chris Goldsworthy]

On 2020-09-11 14:37, Florian Fainelli wrote:
> On 9/11/2020 1:54 PM, Chris Goldsworthy wrote:
> > CMA allocations will fail if 'pinned' pages are in a CMA area, since 
> > we
> > cannot migrate pinned pages. The _refcount of a struct page being 
> > greater
> > than _mapcount for that page can cause pinning for anonymous pages.  
> > This
> > is because try_to_unmap(), which (1) is called in the CMA allocation 
> > path,
> > and (2) decrements both _refcount and _mapcount for a page, will stop
> > unmapping a page from VMAs once the _mapcount for a page reaches 0.  
> > This
> > implies that after try_to_unmap() has finished successfully for a page
> > where _recount > _mapcount, that _refcount will be greater than 0.  
> > Later
> > in the CMA allocation path in migrate_page_move_mapping(), we will 
> > have one
> > more reference count than intended for anonymous pages, meaning the
> > allocation will fail for that page.
> >
> > One example of where _refcount can be greater than _mapcount for a 
> > page we
> > would not expect to be pinned is inside of copy_one_pte(), which is 
> > called
> > during a fork. For ptes for which pte_present(pte) == true, 
> > copy_one_pte()
> > will increment the _refcount field followed by the  _mapcount field of 
> > a
> > page. If the process doing copy_one_pte() is context switched out 
> > after
> > incrementing _refcount but before incrementing _mapcount, then the 
> > page
> > will be temporarily pinned.
> >
> > So, inside of cma_alloc(), instead of giving up when 
> > alloc_contig_range()
> > returns -EBUSY after having scanned a whole CMA-region bitmap, perform
> > retries indefinitely, with sleeps, to give the system an opportunity 
> > to
> > unpin any pinned pages.
>
> I am by no means an authoritative CMA person but this behavior does
> not seem acceptable, there is no doubt the existing one is sub-optimal
> under specific circumstances, but an indefinite retry, as well as a
> 100ms sleep appear to be arbitrary at best. How about you introduce a
> parameter that allows the tuning of the number of retries and/or delay
> between retries?

Apologies Florian, I messed up on the threading and there are 
discussions that aren't reference here.  The original version of this 
patch was doing a finite number of retires.  Also, this e-mail was just 
sent out to LKML so I could debug some issues I was facing with git 
send-email.  The actual thread is now here, which summarizes the 
discussions w.r.t. this patch so far:  
https://lkml.org/lkml/2020/9/14/1097

Thanks,

Chris.

--
The Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,
a Linux Foundation Collaborative Project