Re: cma_alloc(), add sleep-and-retry for temporary page pinning

[Chris Goldsworthy]

On 2020-08-21 15:01, Andrew Morton wrote:
> On Tue, 11 Aug 2020 15:20:47 -0700 cgoldswo@xxxxxxxxxxxxxx wrote:
>
> > One
> > thing to stress is that there are other instances of CMA page pinning,
> > that
> > this patch isn't attempting to address.
>
> Oh.  How severe are these?

Hey Andrew,

  - get_user_pages() will pin pages (I think that's a 100% guarantee but 
I'd need to double check that). There isn't a workaround for this as far 
as I know.
  - One issue we've encountered is when the pages for buffer heads are 
stuck on an LRU list (see the call to buffer_busy() in drop_buffers() 
https://elixir.bootlin.com/linux/v5.8.8/source/fs/buffer.c#L3225). We 
deal with this by allowing the buffers to be dropped, if the reason 
buffer_busy() returns true is because the page is on an LRU list.

> Well.  Why not wait infinitely?  Because there are other sources of CMA
> page pinning, I guess.
>
> Could we take a sleeping lock on the exit_mmap() path and on the
> migration path?  So that the migration path automatically waits for
> the exact amount of time?

Retrying indefinitely whilst alloc_contig_range() returns -EBUSY is 
actually a viable approach.  From the perspective of how long it takes 
to perform a CMA allocation, it is preferable compared to the lock-based 
method, in terms of how long it would take to do a CMA allocation.  With 
our current method, we attempt allocations across an entire CMA region 
before sleeping and retrying. With the lock-based method, we'd be 
sleeping on a per-page basis - this could lead to a situation where we 
spend a great deal of time waiting for a particular page A to be freed, 
that lies in the subset of the CMA region we're allocating form.  We 
could have instead given up on allocating that subset of the CMA region 
(because page A is pinned), and have moved on to a different subset of 
the CMA region, and have successfully allocated that subset, whilst page 
A is still pinned.

I have a patch ready that does this indefinite-retrying, that will be 
sent in reply to this e-mail.

Regards,

Chris.

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