From: Paul Jackson <pj@sgi.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Mel Gorman <mel@csn.ul.ie>,
linux-kernel@vger.kernel.org,
Dinakar Guniguntala <dino@in.ibm.com>,
Joel Schopp <jschopp@austin.ibm.com>,
Simon Derr <Simon.Derr@bull.net>,
Linus Torvalds <torvalds@osdl.org>, Paul Jackson <pj@sgi.com>,
Dave Hansen <haveblue@us.ibm.com>
Subject: [PATCH 2/4] cpusets new __GFP_HARDWALL flag
Date: Thu, 1 Sep 2005 02:09:05 -0700 (PDT) [thread overview]
Message-ID: <20050901090905.18441.86997.sendpatchset@jackhammer.engr.sgi.com> (raw)
In-Reply-To: <20050901090853.18441.24035.sendpatchset@jackhammer.engr.sgi.com>
Add another GFP flag: __GFP_HARDWALL.
A subsequent "cpuset_zone_allowed" patch will use this flag to mark
GFP_USER allocations, and distinguish them from GFP_KERNEL allocations.
Allocations (such as GFP_USER) marked GFP_HARDWALL are constrainted to
the current tasks cpuset. Other allocations (such as GFP_KERNEL) can
steal from the possibly larger nearest mem_exclusive cpuset ancestor,
if memory is tight on every node in the current cpuset.
This patch collides with Mel Gorman's patch to reduce fragmentation
in the standard buddy allocator, which adds two GFP flags. This was
discussed on linux-mm in July. Most likely, one of his flags for
user reclaimable memory can be the same as my __GFP_HARDWALL flag,
under some generic name meaning its user address space memory.
Signed-off-by: Paul Jackson <pj@sgi.com>
Index: linux-2.6.13-mem_exclusive_oom/include/linux/gfp.h
===================================================================
--- linux-2.6.13-mem_exclusive_oom.orig/include/linux/gfp.h
+++ linux-2.6.13-mem_exclusive_oom/include/linux/gfp.h
@@ -40,6 +40,7 @@ struct vm_area_struct;
#define __GFP_ZERO 0x8000u /* Return zeroed page on success */
#define __GFP_NOMEMALLOC 0x10000u /* Don't use emergency reserves */
#define __GFP_NORECLAIM 0x20000u /* No realy zone reclaim during allocation */
+#define __GFP_HARDWALL 0x40000u /* Enforce hardwall cpuset memory allocs */
#define __GFP_BITS_SHIFT 20 /* Room for 20 __GFP_FOO bits */
#define __GFP_BITS_MASK ((1 << __GFP_BITS_SHIFT) - 1)
@@ -48,14 +49,15 @@ struct vm_area_struct;
#define GFP_LEVEL_MASK (__GFP_WAIT|__GFP_HIGH|__GFP_IO|__GFP_FS| \
__GFP_COLD|__GFP_NOWARN|__GFP_REPEAT| \
__GFP_NOFAIL|__GFP_NORETRY|__GFP_NO_GROW|__GFP_COMP| \
- __GFP_NOMEMALLOC|__GFP_NORECLAIM)
+ __GFP_NOMEMALLOC|__GFP_NORECLAIM|__GFP_HARDWALL)
#define GFP_ATOMIC (__GFP_HIGH)
#define GFP_NOIO (__GFP_WAIT)
#define GFP_NOFS (__GFP_WAIT | __GFP_IO)
#define GFP_KERNEL (__GFP_WAIT | __GFP_IO | __GFP_FS)
-#define GFP_USER (__GFP_WAIT | __GFP_IO | __GFP_FS)
-#define GFP_HIGHUSER (__GFP_WAIT | __GFP_IO | __GFP_FS | __GFP_HIGHMEM)
+#define GFP_USER (__GFP_WAIT | __GFP_IO | __GFP_FS | __GFP_HARDWALL)
+#define GFP_HIGHUSER (__GFP_WAIT | __GFP_IO | __GFP_FS | __GFP_HARDWALL | \
+ __GFP_HIGHMEM)
/* Flag - indicates that the buffer will be suitable for DMA. Ignored on some
platforms, used as appropriate on others */
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.650.933.1373
next prev parent reply other threads:[~2005-09-01 9:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-01 9:08 [PATCH 0/4] cpusets mems_allowed constrain GFP_KERNEL, oom killer Paul Jackson
2005-09-01 9:08 ` [PATCH 1/4] cpusets oom_kill tweaks Paul Jackson
2005-09-01 9:39 ` Coywolf Qi Hunt
2005-09-01 9:58 ` Paul Jackson
2005-09-01 10:49 ` Coywolf Qi Hunt
2005-09-01 9:09 ` Paul Jackson [this message]
2005-09-01 9:09 ` [PATCH 3/4] cpusets formalize intermediate GFP_KERNEL containment Paul Jackson
2005-09-01 9:09 ` [PATCH 4/4] cpusets confine oom_killer to mem_exclusive cpuset Paul Jackson
2005-09-06 8:08 ` [PATCH 0/4] cpusets mems_allowed constrain GFP_KERNEL, oom killer Paul Jackson
2005-09-06 22:29 ` 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=20050901090905.18441.86997.sendpatchset@jackhammer.engr.sgi.com \
--to=pj@sgi.com \
--cc=Simon.Derr@bull.net \
--cc=akpm@osdl.org \
--cc=dino@in.ibm.com \
--cc=haveblue@us.ibm.com \
--cc=jschopp@austin.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mel@csn.ul.ie \
--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