From: Andi Kleen <ak@muc.de>
To: Matt Tolentino <metolent@snoqualmie.dp.intel.com>
Cc: akpm@osdl.org, apw@shadowen.org, haveblue@us.ibm.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [patch 2/4] add x86-64 Kconfig options for sparsemem
Date: 18 May 2005 18:53:58 +0200
Date: Wed, 18 May 2005 18:53:58 +0200 [thread overview]
Message-ID: <20050518165358.GF88141@muc.de> (raw)
In-Reply-To: <200505181643.j4IGhm7S026977@snoqualmie.dp.intel.com>
On Wed, May 18, 2005 at 09:43:48AM -0700, Matt Tolentino wrote:
> >From: Andi Kleen <ak@muc.de>
> >On Wed, May 18, 2005 at 08:24:41AM -0700, Matt Tolentino wrote:
> >>
> >> Add the requisite arch specific Kconfig options to enable
> >> the use of the sparsemem implementation for NUMA kernels
> >> on x86-64.
> >
> >How much did you test sparsemem on x86-64 NUMA ?
> >
> >There are various cases that probably need to be checked,
> >AMD with SRAT, AMD without SRAT, AMD with more than 4GB RAM,
> >Summit(?), NUMA EMULATION etc.
> >
> >If all that works I would have no problem with removing the
> >old code.
>
> As my disclaimer said, this has only been tested using
> the NUMA EMULATION config option. That's a big part of
> the reason for sending this out - to get further testing
> on real x86-64 NUMA systems, but without breaking the
> current discontigmem code.
Hmm, I would have assumed IBM tested it, since Dave Hansen signed off -
they have a range of Opteron machines. If not I can test it
on a few boxes later.
A single box is not enough, there are various special cases.
e.g. one area I've been fighting with is that
with SRAT and 3+GB memory the nodes don't span the PCI memory
hole anymore, and when there is a virt_to_page() or similar for these
addresses things go wrong because they do a uninitialized hash
table lookup. If it's not that hard and doesn't cause code bloat
I would recommend to harden sparsemem against this case, at least for
upto 4GB.
-Andi
WARNING: multiple messages have this Message-ID (diff)
From: Andi Kleen <ak@muc.de>
To: Matt Tolentino <metolent@snoqualmie.dp.intel.com>
Cc: akpm@osdl.org, apw@shadowen.org, haveblue@us.ibm.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [patch 2/4] add x86-64 Kconfig options for sparsemem
Date: 18 May 2005 18:53:58 +0200
Date: Wed, 18 May 2005 18:53:58 +0200 [thread overview]
Message-ID: <20050518165358.GF88141@muc.de> (raw)
In-Reply-To: <200505181643.j4IGhm7S026977@snoqualmie.dp.intel.com>
On Wed, May 18, 2005 at 09:43:48AM -0700, Matt Tolentino wrote:
> >From: Andi Kleen <ak@muc.de>
> >On Wed, May 18, 2005 at 08:24:41AM -0700, Matt Tolentino wrote:
> >>
> >> Add the requisite arch specific Kconfig options to enable
> >> the use of the sparsemem implementation for NUMA kernels
> >> on x86-64.
> >
> >How much did you test sparsemem on x86-64 NUMA ?
> >
> >There are various cases that probably need to be checked,
> >AMD with SRAT, AMD without SRAT, AMD with more than 4GB RAM,
> >Summit(?), NUMA EMULATION etc.
> >
> >If all that works I would have no problem with removing the
> >old code.
>
> As my disclaimer said, this has only been tested using
> the NUMA EMULATION config option. That's a big part of
> the reason for sending this out - to get further testing
> on real x86-64 NUMA systems, but without breaking the
> current discontigmem code.
Hmm, I would have assumed IBM tested it, since Dave Hansen signed off -
they have a range of Opteron machines. If not I can test it
on a few boxes later.
A single box is not enough, there are various special cases.
e.g. one area I've been fighting with is that
with SRAT and 3+GB memory the nodes don't span the PCI memory
hole anymore, and when there is a virt_to_page() or similar for these
addresses things go wrong because they do a uninitialized hash
table lookup. If it's not that hard and doesn't cause code bloat
I would recommend to harden sparsemem against this case, at least for
upto 4GB.
-Andi
--
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:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2005-05-18 16:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-18 16:43 [patch 2/4] add x86-64 Kconfig options for sparsemem Matt Tolentino
2005-05-18 16:43 ` Matt Tolentino
2005-05-18 16:53 ` Andi Kleen [this message]
2005-05-18 16:53 ` Andi Kleen
2005-05-19 14:53 ` Dave Hansen
2005-05-19 14:53 ` Dave Hansen
-- strict thread matches above, loose matches on Subject: below --
2005-05-18 15:24 Matt Tolentino
2005-05-18 15:24 ` Matt Tolentino
2005-05-18 16:25 ` Andi Kleen
2005-05-18 16:25 ` Andi Kleen
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=20050518165358.GF88141@muc.de \
--to=ak@muc.de \
--cc=akpm@osdl.org \
--cc=apw@shadowen.org \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=metolent@snoqualmie.dp.intel.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 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.