linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Yasunori Goto <ygoto@us.fujitsu.com>
To: keith <kmannth@us.ibm.com>
Cc: external hotplug mem list <lhms-devel@lists.sourceforge.net>,
	linux-mm <linux-mm@kvack.org>, Chris McDermott <lcm@us.ibm.com>
Subject: Re: [Lhms-devel] [RFC] fix for hot-add enabled SRAT/BIOS and numa KVA areas
Date: Wed, 17 Nov 2004 14:33:43 -0800	[thread overview]
Message-ID: <20041117133315.92B7.YGOTO@us.fujitsu.com> (raw)
In-Reply-To: <1100659057.26335.125.camel@knk>

Hello, Keith-san.

>   This chunk extends from the end of physical memory to the end of the
> i386 address space.  If the following my physical memory is 0x2C0000. 
> 
> (From the boot messages)
> Memory range 0x80000 to 0xC0000 (type 0x0) in proximity domain 0x01 enabled
> Memory range 0x100000 to 0x2C0000 (type 0x0) in proximity domain 0x01 enabled
> Memory range 0x2C0000 to 0x1000000 (type 0x0) in proximity domain 0x01 enabled and removable
>   
>   These memory ranges I believe to be valid according to what I know
> about the SRAT and the ACPI 2.0c specs.  (I am not an ACPI expert please
> correct me if I am wrong!)

I also think this is valid. Probably the firmware of x445 thought, 
if enabled bit of SRAT is off, any other information of its area
will not be trusted.
So, there is no way to distinguish the machine can't attach more memory
from it can do it (just there is no memory AT BOOT TIME.)
So, third area in this boot message just indicates "possibility" of hotadd
memory.
But e820 probably indicates just memory areas which 
are already connected on the board, right?

(IIRC, there is no mention about if enable bit of SRAT is off
 in SRAT spec.)

BTW, I have a question.
  - Can x445 be attached memory without removing the node?
    In my concern machine, there is no physical space to
    hot add or exchange memory without physical removing
    the node. But, this SRAT table indicate that
    all of proximity is 0x01....
    Or is it just logical attachment?

Thanks.

-- 
Yasunori Goto <ygoto at us.fujitsu.com>


--
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>

  parent reply	other threads:[~2004-11-17 22:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-17  2:37 keith
2004-11-17 17:11 ` [Lhms-devel] " Dave Hansen
2004-11-18  2:08   ` keith
2004-11-18  2:24     ` Dave Hansen
2004-11-18 19:18       ` keith
2004-11-17 22:33 ` Yasunori Goto [this message]
2004-11-17 22:42   ` Dave Hansen
2004-11-17 23:21     ` Yasunori Goto
2004-11-18  2:18     ` keith
2004-11-18  2:16   ` keith

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=20041117133315.92B7.YGOTO@us.fujitsu.com \
    --to=ygoto@us.fujitsu.com \
    --cc=kmannth@us.ibm.com \
    --cc=lcm@us.ibm.com \
    --cc=lhms-devel@lists.sourceforge.net \
    --cc=linux-mm@kvack.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