It appears that when CMA is enabled, the zone watermarks are not properly
respected, leading to for example GFP_NOWAIT allocations getting access to the
high pools.

I ran the following test code which simply allocates pages with GFP_NOWAIT
until it fails, and then tries GFP_ATOMIC.  Without CMA, the GFP_ATOMIC
allocation succeeds, with CMA, it fails too.

Logs attached (includes my patch which prints the migration type in the failure
message http://marc.info/?l=linux-mm&m=134971041701306&w=2), taken on 3.6
kernel.

Thanks.

diff --git a/arch/arm/mach-ux500/board-mop500.c
b/arch/arm/mach-ux500/board-mop500.c
index a534d88..b98d0df 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -854,3 +854,25 @@ DT_MACHINE_START(U8500_DT, "ST-Ericsson U8500
platform (Device Tree Support)")
        .dt_compat      = u8500_dt_board_compat,
 MACHINE_END
 #endif
+
+static int __init late(void)
+{
+       while (1) {
+               void *p;
+
+               p = alloc_page(GFP_NOWAIT);
+               if (!p) {
+                       pr_err("GFP_NOWAIT failed, checking GFP_ATOMIC");
+
+                       p = alloc_page(GFP_ATOMIC);
+                       if (!p)
+                               panic("GFP_ATOMIC failed too, fail!");
+
+                       panic("GFP_ATOMIC OK, all good\n");
+               }
+
+       }
+
+       return 0;
+}
+late_initcall(late);

Attachment: cmalog.txt.gz
Description: GNU Zip compressed data

Reply via email to