[lkml]   [2020]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [rfc v2 3/6] dma-pool: dynamically expanding atomic pools
On Fri, 10 Apr 2020, Hillf Danton wrote:

> On Wed, 8 Apr 2020 14:21:06 -0700 (PDT) David Rientjes wrote:
> >
> > When an atomic pool becomes fully depleted because it is now relied upon
> > for all non-blocking allocations through the DMA API, allow background
> > expansion of each pool by a kworker.
> >
> > When an atomic pool has less than the default size of memory left, kick
> > off a kworker to dynamically expand the pool in the background. The pool
> > is doubled in size, up to MAX_ORDER-1. If memory cannot be allocated at
> > the requested order, smaller allocation(s) are attempted.
> >
> What is proposed looks like a path of single lane without how to
> dynamically shrink the pool taken into account. Thus the risk may
> rise in corner cases where pools are over-expanded in long run
> after one-off peak allocation requests.

To us, this is actually a benefit: we prefer the peak size to be
maintained so that we do not need to dynamic resize the pool later at the
cost of throughput. Genpool also does not have great support for
scavenging and freeing unused chunks.

Perhaps we could enforce a maximum size on the pools just as we allow the
default size to be defined by coherent_size= on the command line. Our use
case would not set this, however, since we have not seen egregious genpool
sizes as the result of non-blockable DMA allocations (perhaps the drivers
we use just play friendlier and you have seen excessive usage?).

I'll rely on Christoph to determine whether it makes sense to add some
periodic scavening of the atomic pools, whether that's needed for this to
be merged, or wheter we should enforce some maximum pool size.

 \ /
  Last update: 2020-04-10 21:37    [W:0.216 / U:12.812 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site