From: Paul Jackson <pj@sgi.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Andrew Morton <akpm@osdl.org>, Simon Derr <Simon.Derr@bull.net>,
Paul Jackson <pj@sgi.com>,
linux-kernel@vger.kernel.org
Subject: [PATCH 2.6.12-rc1] cpusets special case GFP_ATOMIC allocs
Date: Sat, 26 Mar 2005 22:52:21 -0800 (PST) [thread overview]
Message-ID: <20050327065222.25762.37675.sendpatchset@sam.engr.sgi.com> (raw)
Stringent enforcement of cpuset memory placement could cause
the kernel to panic on a GFP_ATOMIC (!wait) memory allocation,
even though memory was available elsewhere in the system.
Relax the cpuset constraint, on the last zone loop in
mm/page_alloc.c:__alloc_pages(), for ATOMIC requests.
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-26 22:34:46.000000000 -0800
+++ 2.6.12-pj/Documentation/cpusets.txt 2005-03-26 22:34:47.000000000 -0800
@@ -262,6 +262,14 @@ that has had all its allowed CPUs or Mem
code should reconfigure cpusets to only refer to online CPUs and Memory
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.
+
To start a new job that is to be contained within a cpuset, the steps are:
1) mkdir /dev/cpuset
Index: 2.6.12-pj/mm/page_alloc.c
===================================================================
--- 2.6.12-pj.orig/mm/page_alloc.c 2005-03-26 22:34:38.000000000 -0800
+++ 2.6.12-pj/mm/page_alloc.c 2005-03-26 22:47:49.000000000 -0800
@@ -780,6 +780,9 @@ __alloc_pages(unsigned int gfp_mask, uns
/*
* Go through the zonelist again. Let __GFP_HIGH and allocations
* 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.
*/
for (i = 0; (z = zones[i]) != NULL; i++) {
if (!zone_watermark_ok(z, order, z->pages_min,
@@ -787,7 +790,7 @@ __alloc_pages(unsigned int gfp_mask, uns
gfp_mask & __GFP_HIGH))
continue;
- if (!cpuset_zone_allowed(z))
+ if (wait && !cpuset_zone_allowed(z))
continue;
page = buffered_rmqueue(z, order, gfp_mask);
--
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
next reply other threads:[~2005-03-27 6:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-27 6:52 Paul Jackson [this message]
2005-03-27 6:59 ` [PATCH 2.6.12-rc1] cpusets special case GFP_ATOMIC allocs Nick Piggin
2005-03-27 9:14 ` Paul Jackson
2005-03-28 7:03 ` [PATCH 2.6.12-rc1] cpusets GFP_ATOMIC fix: tonedown panic comment Paul Jackson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050327065222.25762.37675.sendpatchset@sam.engr.sgi.com \
--to=pj@sgi.com \
--cc=Simon.Derr@bull.net \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox