From: "Yinghai Lu" <yhlu.kernel@gmail.com>
To: "Johannes Weiner" <hannes@saeurebad.de>
Cc: "Ingo Molnar" <mingo@elte.hu>,
akpm@linux-foundation.org, mm-commits@vger.kernel.org,
ak@suse.de, clameter@sgi.com, kamezawa.hiroyu@jp.fujitsu.com,
y-goto@jp.fujitsu.com, linux-kernel@vger.kernel.org
Subject: Re: + bootmem-node-setup-agnostic-free_bootmem.patch added to -mm tree
Date: Tue, 15 Apr 2008 13:03:53 -0700 [thread overview]
Message-ID: <86802c440804151303k29295e9bp70c1046b8c9dca76@mail.gmail.com> (raw)
In-Reply-To: <87mynuhp0o.fsf@saeurebad.de>
On Tue, Apr 15, 2008 at 12:55 PM, Johannes Weiner <hannes@saeurebad.de> wrote:
> Hi,
>
>
>
> "Yinghai Lu" <yhlu.kernel@gmail.com> writes:
>
> > On Tue, Apr 15, 2008 at 5:51 AM, Johannes Weiner <hannes@saeurebad.de> wrote:
> >> Hi Ingo,
> >>
> >>
> >>
> >> Ingo Molnar <mingo@elte.hu> writes:
> >>
> >> > * akpm@linux-foundation.org <akpm@linux-foundation.org> wrote:
> >> >
> >> >> Subject: bootmem: node-setup agnostic free_bootmem()
> >> >> From: Johannes Weiner <hannes@saeurebad.de>
> >> >>
> >> >> Make free_bootmem() look up the node holding the specified address
> >> >> range which lets it work transparently on single-node and multi-node
> >> >> configurations.
> >> >
> >> > this patch does not fix the bug Yinghai's (now dropped) patches solved:
> >> > reserve_early() allocations. So NAK until the full problem has been
> >> > sorted out ...
> >>
> >> Okay, NAK on -mm and -x86 for sure. The patch was meant for mainline
> >> where there is no need for free_bootmem() going across nodes, right?
> >>
> >> But I still object to the way Yinghai implemented it.
> >> free_bootmem_core() should not be twisted like this.
> >>
> >> How about the following (untested, even uncompiled, but you should get
> >> the idea) proposal which would replace the patch discussed in this
> >> thread:
> >>
> >> --- tree-linus.orig/mm/bootmem.c
> >> +++ tree-linus/mm/bootmem.c
> >> @@ -421,7 +421,25 @@ int __init reserve_bootmem(unsigned long
> >>
> >>
> >> void __init free_bootmem(unsigned long addr, unsigned long size)
> >> {
> >> - free_bootmem_core(NODE_DATA(0)->bdata, addr, size);
> >> + bootmem_data_t *bdata;
> >> +
> >> + list_for_each_entry(bdata, &bdata_list, list) {
> >> + unsigned long remainder = 0;
> >>
> >> +
> >> + if (addr < bdata->node_boot_start)
> >> + continue;
> >> +
> >> + if (PFN_DOWN(addr + size) > bdata->node_low_pfn)
> >> + remainder = PFN_DOWN(addr + size) - bdata->node_low_pfn;
> >> +
> >> + size -= PFN_PHYS(remainder);
> >>
> >> + free_bootmem_core(bdata, addr, size)
> >> +
> >> + if (!remainder)
> >> + break;
> >> +
> >> + addr = PFN_PHYS(bdata->node_low_pfn + 1);
> >> + }
> >>
> >> }
> >>
> >> unsigned long __init free_all_bootmem(void)
> >
> > how about
> > 1. bdata is not sorted?
>
> They are kept in a sorted list. How could they be unsorted?
>
>
> > 2. intel cross node box: node0: 0g-2g, 4g-6g, node1: 2g-4g, 6g-8g. i
> > don't think they have two bdata struct for every node.
>
> How do the bdata structures represent this setup right now? Are you
> sure that there is not a node descriptor for every contiguous region?
http://lkml.org/lkml/2008/3/25/233
Subject [patch] srat, x86_64: Add support for nodes spanning other nodes
For example, If the physical address layout on a two node system with 8 GB
memory is something like:
node 0: 0-2GB, 4-6GB
node 1: 2-4GB, 6-8GB
Current kernels fail to boot/detect this NUMA topology.
ACPI SRAT tables can expose such a topology which needs to be supported.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
YH
next prev parent reply other threads:[~2008-04-15 20:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200804150623.m3F6NInZ014509@imap1.linux-foundation.org>
2008-04-15 7:02 ` Yinghai Lu
2008-04-15 7:11 ` Ingo Molnar
2008-04-15 12:51 ` Johannes Weiner
2008-04-15 13:41 ` Roel Kluin
2008-04-15 14:01 ` Johannes Weiner
2008-04-15 18:57 ` Yinghai Lu
2008-04-15 19:55 ` Johannes Weiner
2008-04-15 20:03 ` Yinghai Lu [this message]
2008-04-15 21:14 ` Johannes Weiner
2008-04-15 21:19 ` Yinghai Lu
2008-04-15 21:38 ` Johannes Weiner
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=86802c440804151303k29295e9bp70c1046b8c9dca76@mail.gmail.com \
--to=yhlu.kernel@gmail.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=hannes@saeurebad.de \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mm-commits@vger.kernel.org \
--cc=y-goto@jp.fujitsu.com \
/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
all inboxes | Powered by JetHome®