> > Normally, even when memory is freed it is cached until > > SLEEP memory allocation fails, and then it is > > re-allocated. Is this your memory leak? So, memory > > tends to so up as more and more allocated and never > > decreased from a point, IMO. > > That's not the case for FreeBSD. I wasn't clear, but statistics I used > shows me both used and freed, but kept around elements. And what I > posted what the number of really used elements.
This isn't the case for Solaris, either. KM_SLEEP allocations _never_ fail, which is why there's the option for KM_NOSLEEP. I presume that this is really a description of vmem_xalloc; however, this isn't an accurate description either. vmem_xalloc() calls kmem_reap() when it fails to find vmem that it can allocate. The code which checks whether VM_NOSLEEP has been set is after the call to kmem_reap(). If NOSLEEP is set, vmem_xalloc() breaks out of its loop and returns NULL. If SLEEP is set, the routine ends up sleeping on the vmp->vm_cv. Waiters here are awoken by a broadcast in vmem_freelist_insert() and vmem_update(). There's also a thread in kmem which checks the caches once every 15 seconds. This thread will perform hashtable and magazine resizing. If it resizes a magazine, it will purge the contents of the magazine layer before instantiating a re-sized set. This will free memory back to the system. See kmem_update(). Since this is a cache, the system tries to leave the memory available, since allocating it from scratch is expensive. kmem_reap() is called in about 9 places in the kernel where we might get especially tight on free memory. -j
