From: Magnus Damm <magnus.damm@gmail.com>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: Magnus Damm <magnus@valinux.co.jp>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
"A. P. Whitcroft [imap]" <andyw@uk.ibm.com>
Subject: Re: [PATCH] i386: single node SPARSEMEM fix
Date: Thu, 8 Sep 2005 10:40:39 +0900 [thread overview]
Message-ID: <aec7e5c3050907184033423e69@mail.gmail.com> (raw)
In-Reply-To: <1126114116.7329.16.camel@localhost>
On 9/8/05, Dave Hansen <haveblue@us.ibm.com> wrote:
> On Tue, 2005-09-06 at 12:56 +0900, Magnus Damm wrote:
> > This patch for 2.6.13-git5 fixes single node sparsemem support. In the case
> > when multiple nodes are used, setup_memory() in arch/i386/mm/discontig.c calls
> > get_memcfg_numa() which calls memory_present(). The single node case with
> > setup_memory() in arch/i386/kernel/setup.c does not call memory_present()
> > without this patch, which breaks single node support.
>
> First of all, this is really a feature addition, not a bug fix. :)
>From the POV that you can use sparsemem on a PC, yes. But from the POV
that setup_memory() in arch/i386/kernel/setup.c not includes a call to
memory_present(), I think it is a fix. =)
While at it, why do we have two copies of setup_memory()? Couldn't
NUMA and non-NUMA share the same code? OTOH, NUMA and discontigmem
seems very integrated/mixed up and there seems to be much activity in
this field so maybe it is nice to keep the NUMA part separated anyway.
> The reason we haven't included this so far is that we don't really have
> any machines that need sparsemem on i386 that aren't NUMA. So, we
> disabled it for now, and probably need to decide first why we need it
> before a patch like that goes in.
Well, I do not have any hardware here that requires sparsemem either,
but I wanted to add NUMA emulation code to be able to run some
multiple-memory-nodes tests on a virtual PC in QEMU. And this little
patch shows my first step which involved getting sparsememto run on a
PC.
> I actually have exactly the same patch that you sent out in my tree, but
> it's just for testing. Magnus, perhaps we can get some of my testing
> patches in good enough shape to put them in -mm so that the non-NUMA
> folks can do more sparsemem testing.
Well, my NUMA emulation project has been postponed a bit now, but
sooner or later I or someone else will need sparsemem on non-NUMA. So
getting your testing patches in to -mm seems like a good idea!
Thanks!
/ magnus
WARNING: multiple messages have this Message-ID (diff)
From: Magnus Damm <magnus.damm@gmail.com>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: Magnus Damm <magnus@valinux.co.jp>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
"A. P. Whitcroft [imap]" <andyw@uk.ibm.com>
Subject: Re: [PATCH] i386: single node SPARSEMEM fix
Date: Thu, 8 Sep 2005 10:40:39 +0900 [thread overview]
Message-ID: <aec7e5c3050907184033423e69@mail.gmail.com> (raw)
In-Reply-To: <1126114116.7329.16.camel@localhost>
On 9/8/05, Dave Hansen <haveblue@us.ibm.com> wrote:
> On Tue, 2005-09-06 at 12:56 +0900, Magnus Damm wrote:
> > This patch for 2.6.13-git5 fixes single node sparsemem support. In the case
> > when multiple nodes are used, setup_memory() in arch/i386/mm/discontig.c calls
> > get_memcfg_numa() which calls memory_present(). The single node case with
> > setup_memory() in arch/i386/kernel/setup.c does not call memory_present()
> > without this patch, which breaks single node support.
>
> First of all, this is really a feature addition, not a bug fix. :)
>From the POV that you can use sparsemem on a PC, yes. But from the POV
that setup_memory() in arch/i386/kernel/setup.c not includes a call to
memory_present(), I think it is a fix. =)
While at it, why do we have two copies of setup_memory()? Couldn't
NUMA and non-NUMA share the same code? OTOH, NUMA and discontigmem
seems very integrated/mixed up and there seems to be much activity in
this field so maybe it is nice to keep the NUMA part separated anyway.
> The reason we haven't included this so far is that we don't really have
> any machines that need sparsemem on i386 that aren't NUMA. So, we
> disabled it for now, and probably need to decide first why we need it
> before a patch like that goes in.
Well, I do not have any hardware here that requires sparsemem either,
but I wanted to add NUMA emulation code to be able to run some
multiple-memory-nodes tests on a virtual PC in QEMU. And this little
patch shows my first step which involved getting sparsememto run on a
PC.
> I actually have exactly the same patch that you sent out in my tree, but
> it's just for testing. Magnus, perhaps we can get some of my testing
> patches in good enough shape to put them in -mm so that the non-NUMA
> folks can do more sparsemem testing.
Well, my NUMA emulation project has been postponed a bit now, but
sooner or later I or someone else will need sparsemem on non-NUMA. So
getting your testing patches in to -mm seems like a good idea!
Thanks!
/ magnus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2005-09-08 1:40 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-06 3:56 [PATCH] i386: single node SPARSEMEM fix Magnus Damm
2005-09-06 3:56 ` Magnus Damm
2005-09-07 17:28 ` Dave Hansen
2005-09-07 17:28 ` Dave Hansen
2005-09-07 18:22 ` Martin J. Bligh
2005-09-07 18:22 ` Martin J. Bligh
2005-09-07 18:27 ` Dave Hansen
2005-09-07 18:27 ` Dave Hansen
2005-09-07 18:34 ` Martin J. Bligh
2005-09-07 18:34 ` Martin J. Bligh
2005-09-07 23:49 ` Andrew Morton
2005-09-07 23:49 ` Andrew Morton
2005-09-08 0:46 ` Dave Hansen
2005-09-08 0:46 ` Dave Hansen
2005-09-08 1:54 ` Magnus Damm
2005-09-08 1:54 ` Magnus Damm
2005-09-08 6:11 ` Martin J. Bligh
2005-09-08 6:11 ` Martin J. Bligh
2005-09-08 6:36 ` Magnus Damm
2005-09-08 6:36 ` Magnus Damm
2005-09-08 1:51 ` Magnus Damm
2005-09-08 1:51 ` Magnus Damm
2005-09-08 1:45 ` Magnus Damm
2005-09-08 1:45 ` Magnus Damm
2005-09-08 1:40 ` Magnus Damm [this message]
2005-09-08 1:40 ` Magnus Damm
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=aec7e5c3050907184033423e69@mail.gmail.com \
--to=magnus.damm@gmail.com \
--cc=andyw@uk.ibm.com \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=magnus@valinux.co.jp \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.