Re: upcoming kerneloops.org item: get_page_from_freelist

[Linus Torvalds]

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.

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

			Linus
---
 mm/page_alloc.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index aecc9cd..5d714f8 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1153,10 +1153,10 @@ again:
 			 * properly detect and handle allocation failures.
 			 *
 			 * We most definitely don't want callers attempting to
-			 * allocate greater than single-page units with
+			 * allocate greater than order-1 page units with
 			 * __GFP_NOFAIL.
 			 */
-			WARN_ON_ONCE(order > 0);
+			WARN_ON_ONCE(order > 1);
 		}
 		spin_lock_irqsave(&zone->lock, flags);
 		page = __rmqueue(zone, order, migratetype);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/