All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.