Re: Re: [PATCH] mempool: optimize mempool resizing

[Vitaly Wool]

> I think this has unresolved feedback from Christoph [1] and Damien [2],
> so adding them to Cc list.

> [1] https://lore.kernel.org/linux-mm/20260626042252.GA7997@xxxxxx
> [2] https://lore.kernel.org/linux-mm/9104ac5d-ed2b-409d-8220-512dd4581966@xxxxxxxxxx

The first version of the patch was changing the API and the behavior, this one is a pure
optimization that is transparent to all the mempool API users. Therefore, the feedback
from [2] doesn't apply to this patch at all. [1] is answered below.

> On Tue, Oct 13, 2026 at 11:14:08AM +0200, Vitaly Wool wrote:
> > Resizing mempool to a bigger size currently requires a new allocation and
> > a data copy to a new larger elements array which doesn't go well with the
> > idea of having a fast and deadlock free memory allocations during exreme
> > load.
> 
> Please elaborate the problematic scenario more in detail.
> Have you obsesrved the problem in practice?

We are using mempool to store a large set of preallocated rather big buffers. In case
of memory pressure we'd call mempool_resize() (via shrinker callbacks) to reduce the
amount of memory occupied by that set, and when the situation stabilizes, we'd go back
to the original set again.

Imagine you have a mempool with 10000 elements, and you have to reduce it to 3000. Then
if you at some point want to go back to 10000, you'll end up reallocating the elements
array and copying 3000 pointers, which is in fact totally unnecessary becase the array
can still hold 10000 elements but the mempool implementation has no knowledge about it.

Setting mempool to the max from the start a) doesn't help here b) is exhaustive with
regard to the memory usage.

~Vitaly