public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
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).


      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