From: Dave Hansen <dave@sr71.net>
To: Petr Tesarik <ptesarik@suse.cz>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org
Cc: Jiang Liu <liuj97@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Hansen <dave@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86: fix the initialization of physnode_map
Date: Fri, 31 Jan 2014 13:14:29 -0800 [thread overview]
Message-ID: <52EC1235.30909@sr71.net> (raw)
In-Reply-To: <20140131110517.4b7e86d6@hananiah.suse.cz>
On 01/31/2014 02:05 AM, Petr Tesarik wrote:
> With DISCONTIGMEM, the mapping between a pfn and its owning node is
> initialized using data provided by the BIOS or from the command line.
> However, the initialization may fail if the extents are not aligned
> to section boundary (64M).
So is this a problem that shows up with DISCONTIGMEM? Just curious, but
what the heck kind of 32-bit NUMA hardware is still in the wild? Did
someon buy a NUMA-Q on eBay? :)
> void memory_present(int nid, unsigned long start, unsigned long end)
> {
> - unsigned long pfn;
> + unsigned long sect, endsect;
>
> printk(KERN_INFO "Node: %d, start_pfn: %lx, end_pfn: %lx\n",
> nid, start, end);
> printk(KERN_DEBUG " Setting physnode_map array to node %d for pfns:\n", nid);
> printk(KERN_DEBUG " ");
> - for (pfn = start; pfn < end; pfn += PAGES_PER_SECTION) {
> - physnode_map[pfn / PAGES_PER_SECTION] = nid;
> - printk(KERN_CONT "%lx ", pfn);
> + endsect = (end - 1) / PAGES_PER_SECTION;
> + for (sect = start / PAGES_PER_SECTION; sect <= endsect; ++sect) {
> + physnode_map[sect] = nid;
> + printk(KERN_CONT "%lx ", sect * PAGES_PER_SECTION);
> }
> printk(KERN_CONT "\n");
> }
So, if start and end are not aligned to section boundaries, we will miss
setting physnode_map[] for the final section?
For instance, if we have a 64MB section size and try to call
memory_present(32MB -> 96MB), we will set 0->64MB present, but not set
the 64MB->128MB section as present.
Right?
Can you just align 'start' down to the section's start and 'end' up to
the end of the section that contains it? I guess you do that
implicitly, but you should be able to do it without refactoring the for
loop entirely.
next prev parent reply other threads:[~2014-01-31 21:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-31 10:05 Petr Tesarik
2014-01-31 21:02 ` David Rientjes
2014-01-31 21:14 ` Dave Hansen [this message]
2014-02-01 12:13 ` Petr Tesarik
2014-02-01 16:43 ` Dave Hansen
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=52EC1235.30909@sr71.net \
--to=dave@sr71.net \
--cc=akpm@linux-foundation.org \
--cc=dave@linux.vnet.ibm.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=liuj97@gmail.com \
--cc=mingo@redhat.com \
--cc=ptesarik@suse.cz \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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
Powered by JetHome