On Sun, 2011-07-31 at 13:24 -0700, David Rientjes wrote: > And although slub is definitely heading in the right direction regarding > the netperf benchmark, it's still a non-starter for anybody using large > NUMA machines for networking performance. On my 16-core, 4 node, 64GB > client/server machines running netperf TCP_RR with various thread counts > for 60 seconds each on 3.0: > > threads SLUB SLAB diff > 16 76345 74973 - 1.8% > 32 116380 116272 - 0.1% > 48 150509 153703 + 2.1% > 64 187984 189750 + 0.9% > 80 216853 224471 + 3.5% > 96 236640 249184 + 5.3% > 112 256540 275464 + 7.4% > 128 273027 296014 + 8.4% > 144 281441 314791 +11.8% > 160 287225 326941 +13.8% That looks like a pretty nasty scaling issue. David, would it be possible to see 'perf report' for the 160 case? [ Maybe even 'perf annotate' for the interesting SLUB functions. ] On Sun, 2011-07-31 at 13:24 -0700, David Rientjes wrote: > And although I've developed a mutable slab allocator, SLAM, that makes all > of this irrelevant since it's a drop-in replacement for slab and slub, I > can't legitimately propose it for inclusion because it lacks the debugging > capabilities that slub excels in and there's an understanding that Linus > won't merge another stand-alone allocator until one is removed. Nick tried that with SLQB and it didn't work out. I actually even tried to maintain it out-of-tree for a while but eventually gave up. So no, I'm not interested in merging a new allocator either. I would be, however, interested to see the source code. Pekka -- 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>