Some more on SMP scaling: There is also the issue in SLAB that global locks (SMP case) need to be taken for a pretty long timeframe. With a sufficiently high allocation frequency from multiple processors you can cause lock contention on the list_lock that will then degrade performance. SLUB does not take global locks for continued allocations. Global locks are taken for a short time frame if the partial lists need to be updated (which is avoided as much as possible with various measures). This can yield orders of magnitude higher performance The above is possible because of locking at the page level. A queue must either be processor specific or global (or per node) and then would need locks. Another issue is storage density. SLAB needs a metadata structure that either is placed in the slab page itself or in a separate slab cache. In some cases this is advantageous over SLUB (f.e. a series of pointers to objects exist in a single cacheline thus allocation of objects that are not immediately used could be faster) in others it is not (because it increases cache footprint, requires the touching of two slabcaches if the metadata is off slab, makes alignment of objects in the slab pages difficult and increases memory overhead, SLUB generally is faster if the object is/was immediately used since the freepointer overlays the data and thus the cacheline is hot both on alloc and free). -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
