From: David Mosberger <davidm@napali.hpl.hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: PXM/Nid/SLIT patch
Date: Wed, 18 Feb 2004 19:43:15 +0000 [thread overview]
Message-ID: <16435.49235.480070.729149@napali.hpl.hp.com> (raw)
In-Reply-To: <40321CF7.5020301@hp.com>
Bob,
Thanks for your explanation. I'm not very familiar with SRAT, PXM etc
(and don't see much reason at this point why I should read it,
especially considering that it's covered by one of those long
Microsoft licenses), so my preference is for this issue to be worked
out among those folks that care about NUMA (you, Jesse, etc.). In the
unexpected event of not being able to find a solution that's
acceptable to everybody, I'm willing to try to mediate (and learn
about all the RATty stuff.. ;-), but again, I doubt that'll be
necessary.
--david
>>>>> On Wed, 18 Feb 2004 14:19:23 -0500, Robert Picco <Robert.Picco@hp.com> said:
Robert> Our HP default boot configuration has all memory interleaved
Robert> and reported in NUMA SRAT PXM 255. The other cell nodes
Robert> (PXMs) don't have any memory. This was totally unexpected
Robert> by the current NUMA code. There will be N-1 nids with CPUs
Robert> and no memory and 1 NID with all the memory. Initialization
Robert> crashes very early. The current code expects each node to
Robert> have local memory. Well this isn't the case for HP
Robert> machines. It could be configured with some IPMI interface
Robert> for every cell to have Cell Local Memory (CLM) but such an
Robert> interface doesn't exist for Linux. Should such an interface
Robert> become available, the firmware would still steal 0.5Gb of
Robert> interleaved memory from the root cell.
Robert> So, if we had a tool to configure CLM for all cells, there
Robert> would be N-1 nids with CPU and local memory and 1 nid with
Robert> just interleaved memory. The current kernel code would work
Robert> fine but the SLIT information would be wrong because PXM 255
Robert> isn't reported by the firmware in the SLIT table. numa_slit
Robert> isn't used by non-machine dependent code for memory
Robert> allocation policy but could be in the future for memory
Robert> allocations when the current node's memory is
Robert> exhausted. numa_slit would be used as a measure of the best
Robert> locality to make the allocation from (shortest path).
prev parent reply other threads:[~2004-02-18 19:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-17 13:53 PXM/Nid/SLIT patch Robert Picco
2004-02-17 22:32 ` Jesse Barnes
2004-02-18 15:33 ` Robert Picco
2004-02-18 17:08 ` Christoph Hellwig
2004-02-18 18:56 ` Robert Picco
2004-02-18 18:59 ` David Mosberger
2004-02-18 19:04 ` Jesse Barnes
2004-02-18 19:06 ` Jesse Barnes
2004-02-18 19:13 ` Christoph Hellwig
2004-02-18 19:19 ` Robert Picco
2004-02-18 19:36 ` Jesse Barnes
2004-02-18 19:43 ` David Mosberger [this message]
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=16435.49235.480070.729149@napali.hpl.hp.com \
--to=davidm@napali.hpl.hp.com \
--cc=linux-ia64@vger.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