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