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 <[email protected]> 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
