talloc: Other minor issues/queries

[Jeremy Allison]

On Thu, Oct 22, 2020 at 10:57:36AM +0200, Stefan Metzmacher wrote:
> 
> Maybe we could have a FLAG_FIXED_POOL, which avoids the fallback to head memory.
> 
> But I guess we'd need something implemented a bit differently,
> 
> Currently we're very bad at reusing free memory within pools, we don't maintain a free list.
> But that's ok for our two main use cases talloc_stackframe_pool()
> and talloc_pooled_object() for both our main goal is to avoid calling malloc/free more than needed.
> But they don't really implement a SLAB allocator.
> https://en.wikipedia.org/wiki/Slab_allocation
> 
> The Linux kernel has a separation of 'struct kmem_cache' and 'mempool_t', see:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/slab.h
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/slab_def.h
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/mempool.h
> 
> So there's 'mempool_t *mempool_create_slab_pool(int min_nr, struct kmem_cache *kc)'
> and 'mempool_t *mempool_create_kmalloc_pool(int min_nr, size_t size)', but that's all
> for fixed size objects.

I don't think we should mess with pools that much.

They're a specific optimization IMHO with restricted
use.

As I said in the previous email, my first goal is
to get rid of the talloc_memlimit stuff - that's
*horrible* added complexity for very little benefit.

Once that's gone adding FLAG_FIXED_POOL becomes
somewhat easier as there are then only 2 points
inside talloc we fall back to system malloc/realloc
if allocating from POOLMEM fails.

I don't think we should make pools a sub-allocator
with their own freelist. That's not really what
they are designed for.

Jeremy.