On Thursday 15 January 2009 13:04:31 Andrew Morton wrote: > On Wed, 14 Jan 2009 18:21:47 -0700 Matthew Wilcox <matthew@xxxxxx> wrote: > > SLUB would have had a huge negative effect if we were using it -- on the > > order of 7% iirc. SLQB is at least performance-neutral with SLAB. > > We really need to unblock that problem somehow. I assume that > enterprise distros are shipping slab? SLES11 will ship with SLAB, FWIW. As I said in the SLQB thread, this was not due to my input. But I think it was probably the right choice to make in that situation. The biggest problem with SLAB for SGI I think is alien caches bloating the kmem cache footprint to many GB each on their huge systems, but SLAB has a parameter to turn off alien caches anyway so I think that is a reasonable workaround. Given the OLTP regression, and also I'd hate to have to deal with even more reports of people's order-N allocations failing... basically with the regression potential there, I don't think there was a compelling case found to use SLUB (ie. where does it actually help?). I'm going to propose to try to unblock the problem by asking to merge SLQB with a plan to end up picking just one general allocator (and SLOB). Given that SLAB and SLUB are fairly mature, I wonder what you'd think of taking SLQB into -mm and making it the default there for a while, to see if anybody reports a problem? -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
