Subject: Re: __alloc_pages: 0-order allocation failed still in -pre12

From: Andrea Arcangeli <[email-masked]>
Date: Thu, 20 Sep 2001 00:45:43 +0200

On Wed, Sep 19, 2001 at 03:34:41PM -0700, Shane Wegner wrote:
> Hi,
> 
> I'm getting the same thing here.  At least it looks similar
> though I'm not sure what's causing it.  Dual PIII 850, 1gb
							 ^^^ perfect
> ram, 300mb swap.
> 
> __alloc_pages: 0-order allocation failed (gfp=0x20/0) from
> c012e052
> __alloc_pages: 0-order allocation failed (gfp=0x20/0) from
> c012e052
> __alloc_pages: 0-order allocation failed (gfp=0x20/0) from
> c012e052

yes, please try this fix and let me know if it helps:

--- 2.4.10pre11aa1/mm/page_alloc.c.~1~	Tue Sep 18 15:39:50 2001
+++ 2.4.10pre11aa1/mm/page_alloc.c	Thu Sep 20 00:36:11 2001
@@ -369,6 +369,7 @@
 		return NULL;
 	}
 
+ rebalance:
 	page = balance_classzone(classzone, gfp_mask, order, &freed);
 	if (page)
 		return page;
@@ -380,10 +381,13 @@
 			if (!z)
 				break;
 
-			page = rmqueue(z, order);
-			if (page)
-				return page;
+			if (zone_free_pages(z, order) > z->pages_min) {
+				page = rmqueue(z, order);
+				if (page)
+					return page;
+			}
 		}
+		goto rebalance;
 	} else {
 		/* 
 		 * Check that no other task is been killed meanwhile,

Andrea

---

From: Andrea Arcangeli <[email-masked]>
Date: Thu, 20 Sep 2001 04:52:35 +0200

On Wed, Sep 19, 2001 at 07:36:49PM -0700, Shane Wegner wrote:
> On Wed, Sep 19, 2001 at 07:31:28PM -0700, Shane Wegner wrote:
> > On Thu, Sep 20, 2001 at 12:45:43AM +0200, Andrea Arcangeli wrote:
> > After some stress testing, the fix does appear to fix the
> > error.
> 
> Hi,
> 
> Well just after I sent the email, it came up again.
> 
> 
> Sep 19 19:31:52 continuum kernel: __alloc_pages: 0-order
> allocation failed (gfp=0x20/0) from c012e052
> Sep 19 19:33:51 continuum kernel: __alloc_pages: 0-order
> allocation failed (gfp=0x20/0) from c012e052

did it happen as frequently/easily as before or did you need to stress
it much harder? And I'm also curious what happens if we simply lower the
watemark (possibly it was too high). Anyways the other patch is a good
idea to apply anyways.

So can now try the below new one?

--- 2.4.10pre11aa1/mm/page_alloc.c.~1~	Thu Sep 20 00:36:11 2001
+++ 2.4.10pre11aa1/mm/page_alloc.c	Thu Sep 20 04:45:44 2001
@@ -346,7 +346,7 @@
 		if (!z)
 			break;
 
-		if (zone_free_pages(z, order) > (gfp_mask & __GFP_HIGH ? z->pages_min / 2 : z->pages_min)) {
+		if (zone_free_pages(z, order) > (gfp_mask & __GFP_HIGH ? z->pages_min / 4 : z->pages_min)) {
 			page = rmqueue(z, order);
 			if (page)
 				return page;

the fact is, kswapd is the only entity meant to shrink the caches for
the atomic pages, it exactly knows what are the zones that needs to be
balanced and we have a min-min/2 of pages of GAP that must be refilled
in time. It just seems kswapd doesn't cope with the frequency of the
allocations sometime, this may be ok but maybe we must find a way to
more aggressively free memory for the atomic allocations or it could
simply mean that the watermark GAP was too small as Marcelo just
suggested previously.

Can you also resolve "c012e052" so we know who's allocating those pages
just in case?

Andrea