Re: Next June 29: Boot failure with SLQB on s390

[Pekka Enberg <penberg@cs.helsinki.fi>]

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).

On Tue, Jun 30, 2009 at 12:20:10PM +0300, Pekka Enberg wrote:
> > 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.

On Tue, 2009-06-30 at 11:27 +0200, Nick Piggin wrote:
> Well it could, OTOH it should be pretty well in line with SLAB
> after this patch so I don't see much need.

True. But with page allocator fall-through, we don't need to bump up
slab limit to 32 MB (which is pretty damn big IMHO). Anyway, up to you,
really.

			Pekka