Le mercredi 14 décembre 2011 à 08:59 -0600, Christoph Lameter a écrit : > Many people have done patchsets like this. Things changed a lot recently. There is room for improvements. At least we can exchange ideas _before_ coding a new patchset ? > There are various permutations > on SL?B (I dont remember them all SLEB, SLXB, SLQB etc) that have been > proposed over the years. Caches tend to grow and get rather numerous (see > SLAB) and the design of SLUB was to counter that. There is a reason it was > called SLUB. The U stands for Unqueued and was intended to avoid the > excessive caching problems that I ended up when reworking SLAB for NUMA > support. Current 'one active slab' per cpu is a one level cache. It really is a _queue_ containing a fair amount of objects. 'Unqueued' in SLUB is marketing hype :=) When we have one producer (say network interrupt handler) feeding millions of network packets to N consumers (other cpus), each free is slowpath. They all want to touch page->freelist and slow the producer as well because of false sharing. Furthermore, when the producer hits socket queue limits, it mostly frees skbs that were allocated in the 'not very recent past', and its own freeing also hit slow path (because memory blocks of the skb are no longer in the current active slab). It competes with frees done by consumers as well. Adding a second _small_ cache to queue X objects per cpu would help to keep the active slab longer and more 'private' (its 'struct page' not touched too often by other cpus) for a given cpu. It would limit number of cache line misses we currently have because of conflicting accesses to page->freelist just to push one _single_ object (and n->list_lock in less extent) My initial idea would be to use a cache of 4 slots per cpu, but be able to queue many objects per slot, if they all belong to same slab/page. In case we must make room in the cache (all slots occupied), we take one slot and dequeue all objects in one round. No extra latency compared to current schem. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>