From: Paul Jackson This patch applies on top of my patch of March 26, entitled "cpusets special case GFP_ATOMIC allocs". It tones down my panic'y commentary. My commentary shouldn't imply that failed GFP_ATOMICs should lead to, or normally lead to, panics. Even though there are a few panic() calls following failed GFP_ATOMIC allocs, this is not the usual or desired result of a failed GFP_ATOMIC. The kernel will probably drop some detail on the floor and keep on working. Thanks to Nick Piggin for noticing (I hope this answers his point.) Signed-off-by: Paul Jackson Signed-off-by: Andrew Morton --- 25-akpm/Documentation/cpusets.txt | 10 +++++----- 25-akpm/mm/page_alloc.c | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) diff -puN Documentation/cpusets.txt~cpusets-gfp_atomic-fix-tonedown-panic-comment Documentation/cpusets.txt --- 25/Documentation/cpusets.txt~cpusets-gfp_atomic-fix-tonedown-panic-comment 2005-03-30 18:01:49.000000000 -0800 +++ 25-akpm/Documentation/cpusets.txt 2005-03-30 18:01:49.000000000 -0800 @@ -263,11 +263,11 @@ Nodes when using hotplug to add or remov There is a second exception to the above. GFP_ATOMIC requests are kernel internal allocations that must be satisfied, immediately. -The kernel may panic if such a requested page is not allocated. -If such a request cannot be satisfied within the cpusets allowed -memory, then we relax the cpuset boundaries and allow any page in -the system to satisfy a GFP_ATOMIC request. It is better to violate -the cpuset constraints than it is to panic the kernel. +The kernel may drop some request, in rare cases even panic, if a +GFP_ATOMIC alloc fails. If the request cannot be satisfied within +the current tasks cpuset, then we relax the cpuset, and look for +memory anywhere we can find it. It's better to violate the cpuset +than stress the kernel. To start a new job that is to be contained within a cpuset, the steps are: diff -puN mm/page_alloc.c~cpusets-gfp_atomic-fix-tonedown-panic-comment mm/page_alloc.c --- 25/mm/page_alloc.c~cpusets-gfp_atomic-fix-tonedown-panic-comment 2005-03-30 18:01:49.000000000 -0800 +++ 25-akpm/mm/page_alloc.c 2005-03-30 18:01:49.000000000 -0800 @@ -791,7 +791,7 @@ __alloc_pages(unsigned int __nocast gfp_ * coming from realtime tasks to go deeper into reserves * * This is the last chance, in general, before the goto nopage. - * Ignore cpuset if GFP_ATOMIC (!wait) - better that than panic. + * Ignore cpuset if GFP_ATOMIC (!wait) rather than fail alloc. */ for (i = 0; (z = zones[i]) != NULL; i++) { if (!zone_watermark_ok(z, order, z->pages_min, _