Re: [UnifiedV4 00/16] The Unified slab allocator (V4)

[Andi Kleen <andi@firstfloor.org>]

Christoph Lameter <cl@linux.com> writes:

Not looked at code so far, but just comments based on the 
description. But thanks for working on this, it's good
to have alternatives to the ugly slab.c

> V3->V4:
> - Lots of debugging
> - Performance optimizations (more would be good)...
> - Drop per slab locking in favor of per node locking for
>   partial lists (queuing implies freeing large amounts of objects
>   to per node lists of slab).

Is that really a good idea? Nodes (= sockets) are getting larger and 
larger and they are quite substantial SMPs by themselves now.
On Xeon 75xx you have 16 virtual CPUs per node.


> 1. SLUB accurately tracks cpu caches instead of assuming that there
>    is only a single cpu cache per node or system.
>
> 2. SLUB object expiration is tied into the page reclaim logic. There
>    is no periodic cache expiration.

Hmm, but that means that you could fill a lot of memory with caches
before they get pruned right? Is there another limit too?

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>