ChangeSet 1.2230, 2005/03/31 08:27:57-08:00, [EMAIL PROTECTED]
[PATCH] 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 <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Documentation/cpusets.txt | 10 +++++-----
mm/page_alloc.c | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff -Nru a/Documentation/cpusets.txt b/Documentation/cpusets.txt
--- a/Documentation/cpusets.txt 2005-03-31 10:10:05 -08:00
+++ b/Documentation/cpusets.txt 2005-03-31 10:10:05 -08:00
@@ -263,11 +263,11 @@
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 -Nru a/mm/page_alloc.c b/mm/page_alloc.c
--- a/mm/page_alloc.c 2005-03-31 10:10:05 -08:00
+++ b/mm/page_alloc.c 2005-03-31 10:10:05 -08:00
@@ -782,7 +782,7 @@
* 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,
-
To unsubscribe from this list: send the line "unsubscribe bk-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
