From: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Cc: benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au,
anton@samba.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, cl@linux.com,
gkurz@linux.vnet.ibm.com, grant.likely@linaro.org,
nikunj@linux.vnet.ibm.com, khandual@linux.vnet.ibm.com
Subject: Re: [PATCH RFC 0/5] powerpc:numa Add serial nid support
Date: Mon, 28 Sep 2015 10:34:34 -0700 [thread overview]
Message-ID: <20150928173434.GE48470@linux.vnet.ibm.com> (raw)
In-Reply-To: <1443378553-2146-1-git-send-email-raghavendra.kt@linux.vnet.ibm.com>
On 27.09.2015 [23:59:08 +0530], Raghavendra K T wrote:
> Problem description:
> Powerpc has sparse node numbering, i.e. on a 4 node system nodes are
> numbered (possibly) as 0,1,16,17. At a lower level, we map the chipid
> got from device tree is naturally mapped (directly) to nid.
chipid is a OPAL concept, I believe, and not documented in PAPR... How
does this work under PowerVM?
> Potential side effect of that is:
>
> 1) There are several places in kernel that assumes serial node numbering.
> and memory allocations assume that all the nodes from 0-(highest nid)
> exist inturn ending up allocating memory for the nodes that does not exist.
>
> 2) For virtualization use cases (such as qemu, libvirt, openstack), mapping
> sparse nid of the host system to contiguous nids of guest (numa affinity,
> placement) could be a challenge.
>
> Possible Solutions:
> 1) Handling the memory allocations is kernel case by case: Though in some
> cases it is easy to achieve, some cases may be intrusive/not trivial.
> at the end it does not handle side effect (2) above.
>
> 2) Map the sparse chipid got from device tree to a serial nid at kernel
> level (The idea proposed in this series).
> Pro: It is more natural to handle at kernel level than at lower (OPAL) layer.
> con: The chipid is in device tree no longer the same as nid in kernel
Is there any debugging/logging? Looks like not -- so how does a sysadmin
map from firmware-provided values to the Linux values? That's going to
make debugging of large systems (PowerVM or otherwise) less than
pleasant, it seems? Possibly you could put something in sysfs?
-Nish
next prev parent reply other threads:[~2015-09-28 17:34 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-27 18:29 [PATCH RFC 0/5] powerpc:numa Add serial nid support Raghavendra K T
2015-09-27 18:29 ` [PATCH RFC 1/5] powerpc:numa Add numa_cpu_lookup function to update lookup table Raghavendra K T
2015-09-27 18:29 ` Raghavendra K T
2015-09-27 18:41 ` Raghavendra K T
2015-10-06 10:17 ` [RFC, " Michael Ellerman
2015-10-06 10:33 ` Raghavendra K T
2015-09-27 18:29 ` [PATCH RFC 2/5] powerpc:numa Rename functions referring to nid as chipid Raghavendra K T
2015-09-27 18:29 ` Raghavendra K T
2015-09-28 17:27 ` Nishanth Aravamudan
2015-09-29 18:31 ` Raghavendra K T
2015-09-27 18:29 ` [PATCH RFC 3/5] powerpc:numa create 1:1 mappaing between chipid and nid Raghavendra K T
2015-09-27 18:29 ` Raghavendra K T
2015-09-28 17:28 ` Nishanth Aravamudan
2015-09-28 17:28 ` Nishanth Aravamudan
2015-09-29 18:35 ` Raghavendra K T
2015-09-29 18:35 ` Raghavendra K T
2015-09-28 17:35 ` Nishanth Aravamudan
2015-09-28 17:35 ` Nishanth Aravamudan
2015-09-29 19:20 ` Raghavendra K T
2015-09-29 19:20 ` Raghavendra K T
2015-09-27 18:29 ` [PATCH RFC 4/5] powerpc:numa Add helper functions to maintain chipid to nid mapping Raghavendra K T
2015-09-27 18:29 ` Raghavendra K T
2015-09-28 17:32 ` Nishanth Aravamudan
2015-09-29 19:00 ` Raghavendra K T
2015-09-27 18:29 ` [PATCH RFC 5/5] powerpc:numa Use chipid to nid mapping to get serial numa node ids Raghavendra K T
2015-09-27 18:29 ` Raghavendra K T
2015-09-28 10:44 ` [PATCH RFC 0/5] powerpc:numa Add serial nid support Denis Kirjanov
2015-09-28 17:04 ` Nishanth Aravamudan
2015-09-29 18:20 ` Raghavendra K T
2015-09-29 19:46 ` Denis Kirjanov
2015-09-30 6:16 ` Raghavendra K T
2015-09-28 17:34 ` Nishanth Aravamudan [this message]
2015-09-29 19:10 ` Raghavendra K T
2015-10-06 10:25 ` Michael Ellerman
2015-10-06 11:15 ` Raghavendra K T
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=20150928173434.GE48470@linux.vnet.ibm.com \
--to=nacc@linux.vnet.ibm.com \
--cc=anton@samba.org \
--cc=benh@kernel.crashing.org \
--cc=cl@linux.com \
--cc=gkurz@linux.vnet.ibm.com \
--cc=grant.likely@linaro.org \
--cc=khandual@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=nikunj@linux.vnet.ibm.com \
--cc=paulus@samba.org \
--cc=raghavendra.kt@linux.vnet.ibm.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.