[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <84144f020906241144of2c85c7xc5f258a7837896c9@mail.gmail.com>
Date: Wed, 24 Jun 2009 21:44:53 +0300
From: Pekka Enberg <penberg@...helsinki.fi>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>, arjan@...radead.org,
linux-kernel@...r.kernel.org, cl@...ux-foundation.org,
npiggin@...e.de
Subject: Re: upcoming kerneloops.org item: get_page_from_freelist
Hi Linus,
On Wed, 24 Jun 2009, Andrew Morton wrote:
>>
>> hm, I didn't know that slub could fall back to lower-order allocations
>> like that. Neat.
On Wed, Jun 24, 2009 at 9:42 PM, Linus
Torvalds<torvalds@...ux-foundation.org> wrote:
> Slab doesn't do it, though. So we still need to get rid of the "order-1"
> warning, at least (slab_break_gfp_order).
>
>> What's the expected value of s->min in allocate_slab()? In what
>> situations would it be >0?
>
> For slub, s->min has an order of just "get_order(size)" (ie the minimum
> order to fit an object).
>
> For slab, the logic is different, but if I read the code correctly it
> boils down to the minimum order, except that order-1 is accepted instead
> of order-0 (strictly speaking, that only happens if you have more than
> 64MB of RAM). With no fallback.
>
> And it's quite reasonable to expect to be able to do small kmalloc's
> without failing.
>
> So I'd suggest just doing this..
Acked-by: Pekka Enberg <penberg@...helsinki.fi>
That said, I do think we ought to fix SLUB not to use __GFP_FAIL for
the higher order allocation regardless of this patch.
Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists