of free objects an object cache should try to have ready. If the number
of free objects drops below the threshold, a new urgent priority thread
is asked to asynchronously resize the object cache (pretty similar to
the heap grower thread). Such a mechanism is necessary for code paths
that are supposed to free pages, but may need memory themselves (like
the swap support).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27100 a95241bf-73f2-0310-859d-f6bbb57e9c96
* While this is not a really good idea for a lock with supposedly little
contention, but it'll fix bug #1731. I haven't tested it yet, but will
do so in a minute :-)
* I will need to rework the slab anyway so that it's possible to use it
as a replacement for our heap, and then I'll switch back to a benaphore
again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23822 a95241bf-73f2-0310-859d-f6bbb57e9c96
* As a temporary work-around for the current slab allocator's area usage,
I added the CACHE_LARGE_SLAB flag, which will force the allocator to
use larger areas.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23564 a95241bf-73f2-0310-859d-f6bbb57e9c96
- call the reclaimer callback when low on memory.
- use the depot when on multi-cpu setups (for scalability).
- fixed the amount of memory spent on slabs for very large objects.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20889 a95241bf-73f2-0310-859d-f6bbb57e9c96
