From: Andy Whitcroft <apw@shadowen.org>
To: Michael Ellerman <michael@ellerman.id.au>
Cc: Andy Whitcroft <apw@shadowen.org>, Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, haveblue@us.ibm.com,
kravetz@us.ibm.com
Subject: [PATCH] sparsemem record nid during memory present
Date: Wed, 10 May 2006 11:51:02 +0100 [thread overview]
Message-ID: <20060510105102.GA9533@shadowen.org> (raw)
In-Reply-To: <1147241173.8091.21.camel@localhost.localdomain>
Ok, here is the updated version. Better commentry on what we are doing
and how long the data is kept (suggested by Dave Hansen). Also added a
SECTION_NID_SHIFT to better describe its use. This showed a small
buglett as we were shifting by 4 (1<<2) instead of 2; now fixed.
-apw
=== 8< ===
sparsemem record nid during memory present
Record the node id as we mark sections for instantiation. Use this
nid during instantiation to direct allocations.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
include/linux/mmzone.h | 5 +++++
mm/sparse.c | 22 ++++++++++++++++++++--
2 files changed, 25 insertions(+), 2 deletions(-)
diff -upN reference/include/linux/mmzone.h current/include/linux/mmzone.h
--- reference/include/linux/mmzone.h
+++ current/include/linux/mmzone.h
@@ -508,6 +508,10 @@ struct mem_section {
* pages. However, it is stored with some other magic.
* (see sparse.c::sparse_init_one_section())
*
+ * Additionally during early boot we encode node id of
+ * the location of the section here to guide allocation.
+ * (see sparse.c::memory_present())
+ *
* Making it a UL at least makes someone do a cast
* before using it wrong.
*/
@@ -547,6 +551,7 @@ extern int __section_nr(struct mem_secti
#define SECTION_HAS_MEM_MAP (1UL<<1)
#define SECTION_MAP_LAST_BIT (1UL<<2)
#define SECTION_MAP_MASK (~(SECTION_MAP_LAST_BIT-1))
+#define SECTION_NID_SHIFT 2
static inline struct page *__section_mem_map_addr(struct mem_section *section)
{
diff -upN reference/mm/sparse.c current/mm/sparse.c
--- reference/mm/sparse.c
+++ current/mm/sparse.c
@@ -102,6 +102,22 @@ int __section_nr(struct mem_section* ms)
return (root_nr * SECTIONS_PER_ROOT) + (ms - root);
}
+/*
+ * During early boot, before section_mem_map is used for an actual
+ * mem_map, we use section_mem_map to store the section's NUMA
+ * node. This keeps us from having to use another data structure. The
+ * node information is cleared just before we store the real mem_map.
+ */
+static inline unsigned long sparse_encode_early_nid(int nid)
+{
+ return (nid << SECTION_NID_SHIFT);
+}
+
+static inline int sparse_early_nid(struct mem_section *section)
+{
+ return (section->section_mem_map >> SECTION_NID_SHIFT);
+}
+
/* Record a memory area against a node. */
void memory_present(int nid, unsigned long start, unsigned long end)
{
@@ -116,7 +132,8 @@ void memory_present(int nid, unsigned lo
ms = __nr_to_section(section);
if (!ms->section_mem_map)
- ms->section_mem_map = SECTION_MARKED_PRESENT;
+ ms->section_mem_map = sparse_encode_early_nid(nid) |
+ SECTION_MARKED_PRESENT;
}
}
@@ -167,6 +184,7 @@ static int sparse_init_one_section(struc
if (!valid_section(ms))
return -EINVAL;
+ ms->section_mem_map &= ~SECTION_MAP_MASK;
ms->section_mem_map |= sparse_encode_mem_map(mem_map, pnum);
return 1;
@@ -175,8 +193,8 @@ static int sparse_init_one_section(struc
static struct page *sparse_early_mem_map_alloc(unsigned long pnum)
{
struct page *map;
- int nid = early_pfn_to_nid(section_nr_to_pfn(pnum));
struct mem_section *ms = __nr_to_section(pnum);
+ int nid = sparse_early_nid(ms);
map = alloc_remap(nid, sizeof(struct page) * PAGES_PER_SECTION);
if (map)
next prev parent reply other threads:[~2006-05-10 10:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-09 7:03 [PATCH] SPARSEMEM + NUMA can't handle unaligned memory regions? Michael Ellerman
2006-05-09 8:32 ` Andy Whitcroft
2006-05-09 9:11 ` Michael Ellerman
2006-05-09 10:24 ` Andy Whitcroft
2006-05-09 13:34 ` Andy Whitcroft
2006-05-09 14:28 ` Andy Whitcroft
2006-05-09 16:26 ` Dave Hansen
2006-05-09 16:31 ` Andy Whitcroft
2006-05-10 6:06 ` Michael Ellerman
2006-05-10 10:51 ` Andy Whitcroft [this message]
2006-05-09 16:05 ` mike kravetz
2006-05-09 16:14 ` Andy Whitcroft
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=20060510105102.GA9533@shadowen.org \
--to=apw@shadowen.org \
--cc=akpm@osdl.org \
--cc=haveblue@us.ibm.com \
--cc=kravetz@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michael@ellerman.id.au \
/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
Powered by JetHome