RE: [PATCH 1/4] [mm] buddy page allocator: add tunable big order allocation



-----Original Message-----
From: KAMEZAWA Hiroyuki [mailto:kamezawa.hiroyu@xxxxxxxxxxxxxx]
Sent: Dienstag, 13. Mai 2008 04:09
To: Bryan Wu
Cc: linux-kernel@xxxxxxxxxxxxxxx; linux-mm@xxxxxxxxx;
dwmw2@xxxxxxxxxxxxx;
Michael Hennerich
Subject: Re: [PATCH 1/4] [mm] buddy page allocator: add tunable big
order
allocation

On Mon, 12 May 2008 18:32:02 +0800
Bryan Wu <cooloney@xxxxxxxxxx> wrote:

From: Michael Hennerich <michael.hennerich@xxxxxxxxxx>

Signed-off-by: Michael Hennerich <michael.hennerich@xxxxxxxxxx>
Signed-off-by: Bryan Wu <cooloney@xxxxxxxxxx>

Does this really solve your problem ? possible hang-up is better than
page allocation failure ?

On nommu this helped quite a bit, when we run out of memory, eaten up by
the page cache. But yes - with this option it's likely that we sit there
and wait form memory that might never get available.

We now use a better workaround for freeing up "available" memory
currently used as page cache.

I think we should drop this patch.

Best regards,
Michael


---
init/Kconfig | 9 +++++++++
mm/page_alloc.c | 2 +-
2 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index 6135d07..b6ff75b 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -742,6 +742,15 @@ config SLUB_DEBUG
SLUB sysfs support. /sys/slab will not exist and there will be
no support for cache validation etc.

+config BIG_ORDER_ALLOC_NOFAIL_MAGIC
+ int "Big Order Allocation No FAIL Magic"
+ depends on EMBEDDED
+ range 3 10
+ default 3
+ help
+ Let big-order allocations loop until memory gets free.
Specified
Value
+ expresses the order.
+
I think it's better to add a text to explain why this is for EMBEDED.

Thanks,
-Kame
--
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/

Relevant Pages