lkml.org 
[lkml]   [2005]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
Subject[PATCH 2.6.12-rc1] cpusets GFP_ATOMIC fix: tonedown panic comment
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 <pj@sgi.com>

Index: 2.6.12-pj/Documentation/cpusets.txt
===================================================================
--- 2.6.12-pj.orig/Documentation/cpusets.txt 2005-03-27 22:48:14.000000000 -0800
+++ 2.6.12-pj/Documentation/cpusets.txt 2005-03-27 22:48:22.000000000 -0800
@@ -264,11 +264,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:

Index: 2.6.12-pj/mm/page_alloc.c
===================================================================
--- 2.6.12-pj.orig/mm/page_alloc.c 2005-03-27 22:48:14.000000000 -0800
+++ 2.6.12-pj/mm/page_alloc.c 2005-03-27 22:48:42.000000000 -0800
@@ -782,7 +782,7 @@ __alloc_pages(unsigned int gfp_mask, uns
* 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,

--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-04-06 13:31    [W:0.034 / U:1.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site