From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Cc: qemu-ppc@nongnu.org, anton@samba.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] qemu-ppc and NUMA topology
Date: Tue, 20 May 2014 12:44:15 +1000 [thread overview]
Message-ID: <537AC17F.6040605@ozlabs.ru> (raw)
In-Reply-To: <20140520000617.GA29892@linux.vnet.ibm.com>
On 05/20/2014 10:06 AM, Nishanth Aravamudan wrote:
> On 19.05.2014 [15:37:52 -0700], Nishanth Aravamudan wrote:
>> Hi Alexey,
>>
>> I've been looking at hw/ppc/spapr.c::spapr_populate_memory() and ran
>> into a few questions:
>>
>> 1) The values from 1 to nb_numa_nodes are used as indices into the
>> node_mem array, but that is not populated, necessarily, linearly.
>> vl.c::add_node() uses the nodeid parameter as the index into node_mem,
>> if it is specified.
>>
>> 2) The node ID is based upon the index into the array, but it seems like
>> it should actually be based upon the nodeid specified, if any. That is,
>> we set the value at index 4 (which is statically the reference point in
>> 'ibm,associativity-reference-points') of 'ibm,associativty' for each
>> 'ibm,memory@....' node to the index we are currently at. But as
>> mentioned in 1) above that index isn't necessarily currently the nodeid
>> specified on the command-line.
>>
>> What this all means, is that if I specify something like:
>>
>> -numa node,nodeid=1,cpus=0-7,mem=2048 -numa
>> node,nodeid=5,cpus=8-15,mem=0 -numa node,nodeid=9,mem=2048
>>
>> Linux sees:
>>
>> numactl --hardware
>> available: 3 nodes (0-2)
>> node 0 cpus: 8 9 10 11 12 13 14 15
>> node 0 size: 0 MB
>> node 0 free: 0 MB
>> node 1 cpus: 0 1 2 3 4 5 6 7
>> node 1 size: 2024 MB
>> node 1 free: 1560 MB
>> node 2 cpus:
>> node 2 size: 0 MB
>> node 2 free: 0 MB
>>
>> Maybe we don't really care about this, but I just noticed it when trying
>> to reproduce some really weird topologies from PowerVM.
>
> Upon further investigation into node_mem, it seems like this assumption
> is present throughout the qemu code, e.g, the qemu monitor 'info numa'
> command. Will just document it for myself as a weird way to make
> memoryless nodes show up :)
I never looked closely at this NUMA business so I know as much as you do :)
You seem to be right, vl.c seems to get things right (it uses nodeid as an
index) but spapr.c is broken and we probably should fix it but it does not
sound very urgent to me...
--
Alexey
prev parent reply other threads:[~2014-05-20 2:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-19 22:37 [Qemu-devel] qemu-ppc and NUMA topology Nishanth Aravamudan
2014-05-20 0:06 ` Nishanth Aravamudan
2014-05-20 2:44 ` Alexey Kardashevskiy [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=537AC17F.6040605@ozlabs.ru \
--to=aik@ozlabs.ru \
--cc=anton@samba.org \
--cc=nacc@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.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;
as well as URLs for NNTP newsgroup(s).