On Tue, 2009-06-30 at 11:06 +0200, Nick Piggin wrote: > Finally, if KMALLOC_SHIFT_SLQB_HIGH is larger than 2MB, then kmalloc_index > could silently run off the end of its precomputed table and return a -1 > index into the kmalloc slab array, which could result in corruption. Extend > this to allow up to 32MB (to match SLAB), and add a compile-time error in > the case that the table is exceeded (also like SLAB). I wonder if SLQB should just do page allocator pass-through for really big allocations? That way callers don't need to worry about whether they're running under SLAB/SLUB/SLOB/SQLB. Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
