Re: Kernel memory allocation oddities in NetBSD-10.99.12

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	hello.  Thanks for the reply.  If I compare the number of requests with the number of
releases, I get something on the order of 285 active objects for the xnfrx pool.  This leads to
another question.  When pool_cache_put is called by a pool client, is the memory held by that
object held in the pool for re-use by that same pool or is it immediately returned to the
larger kernel memory arena?  If it's held for later use by that pool, where are those ruls
about how many objects to retain for later use and how many to release to the larger memory
arena defined?  I don't see any guidance provided by the client's calls to pool_cache_init as
to what the usage pattern might look like and how the pool allocator might optimize for that.

-thanks
-Brian

On Aug 4,  2:35pm, Greg Troxel wrote:
} Subject: Re: Kernel memory allocation oddities in NetBSD-10.99.12
} Brian Buhrow <buhrow%nfbcal.org@localhost> writes:
} 
} > If execargs can always find 200,000 bytes to allocate, how is it that pcgnormal or xnfrx, which
} > allocate 256 bytes and 4096 bytes respectively, cannot?
} 
} Beware that I am slightly hazy on all things pool.
} 
} If you are using zfs, things are known to be unstable.
} 
} If these are pools, then a pool with free objects can satisfy
} allocations, even if there are no free pages, but a pool with no free
} objects cannot.   
>-- End of excerpt from Greg Troxel