Re: low memory problem - pool calls vmem calls uvm calls pool etc.

[Lars Heidieker <lars%heidieker.de@localhost>]

On 12/09/2013 10:05 PM, David Sainty wrote:
> On 04/12/13 01:07, Lars Heidieker wrote:
>> The recursion happened due to freeing to the wrong arena. Take a look
>> at the pool_allocator_meta and how vmem recurses. It's one vmem arena
>> (kmem_va_arena) using quantum caches and one (actually two
>> kmem_meta_arena(s) stacked on top of kmem_meta_arena) for meta
>> allocations eg pool_allocator_meta those arenas are stacked up on one
>> arena without quatum caching (kmem_arena). So "normal" allocations
>> utilized this cache, but no pool_caches are involved for "meta"
>> allocations. So it might recurse once while switching to allocate via
>> the kmem_meta_arena and from there on no pool_caches are involved.
>> Allocations via vmem_alloc must be freed via vmem_free and vmem_xalloc
>> via vmem_xfree mixing them, at least with quantum caches involved,
>> will lead to inconsistencies. 
> 
> It occurs to me that disabling the quantum cache on the meta arenas may
> be specifically to avoid this problem.  But this problem could also, I
> think, be resolved by ensuring that quantum caching is inhibited in
> vmem_free's in, and only in, ENOMEM paths.  Then quantum caching could
> be used for meta arenas too.
> 
> Is it worth going to that effort?  Would it be much of a win?
> 
> 

Using quantum caching must be symmetrically used, I'm not sure if the
vmem_free paths or ok with quantum caching for the meta arenas...
But vmem_alloc paths aren't really, you have to keep a reserve to
allocate new boundary tags and this reserver is hard to calculate if
allocations recurses more than once due to cache group allocations for
the pool_cache, this will (if possible at all) require serializing the
allocation path right through the pool_cache for meta allocations.
Allocations from the meta arenas don't happen frequently so I don't
think there will be any difference.