diff options
| author | pj@engr.sgi.com <pj@engr.sgi.com> | 2005-03-30 16:27:57 -0800 |
|---|---|---|
| committer | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-03-30 16:27:57 -0800 |
| commit | 85be99bb2797d48af8260ba76044c9f1b3fdd416 (patch) | |
| tree | 9f5bf880f9e0ad8e07bc41b38d70101055f24b04 | |
| parent | 398bec1b785518e2ad87c36f92e542905708ad71 (diff) | |
| download | history-85be99bb2797d48af8260ba76044c9f1b3fdd416.tar.gz | |
[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 <pj@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
| -rw-r--r-- | Documentation/cpusets.txt | 10 | ||||
| -rw-r--r-- | mm/page_alloc.c | 2 |
2 files changed, 6 insertions, 6 deletions
diff --git a/Documentation/cpusets.txt b/Documentation/cpusets.txt index 42c0a8a5e4c59..1ad26d2c20ae6 100644 --- a/Documentation/cpusets.txt +++ b/Documentation/cpusets.txt @@ -263,11 +263,11 @@ Nodes when using hotplug to add or remove such resources. 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 --git a/mm/page_alloc.c b/mm/page_alloc.c index df0668ec286b8..c73dbbc1cd8f5 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -782,7 +782,7 @@ __alloc_pages(unsigned int __nocast gfp_mask, unsigned int order, * 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, |