From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41180) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcllY-0004HC-L1 for qemu-devel@nongnu.org; Mon, 30 Mar 2015 22:18:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YcllX-0002fQ-AN for qemu-devel@nongnu.org; Mon, 30 Mar 2015 22:18:56 -0400 Date: Tue, 31 Mar 2015 13:19:47 +1100 From: David Gibson Message-ID: <20150331021947.GT9908@voom.fritz.box> References: <1427117764-23008-1-git-send-email-bharata@linux.vnet.ibm.com> <1427117764-23008-23-git-send-email-bharata@linux.vnet.ibm.com> <20150326034417.GA11464@voom.redhat.com> <20150330091150.GB4753@in.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="l5oECiFRo5dp+2y7" Content-Disposition: inline In-Reply-To: <20150330091150.GB4753@in.ibm.com> Subject: Re: [Qemu-devel] [RFC PATCH v2 22/23] spapr: Support ibm, dynamic-reconfiguration-memory List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bharata B Rao Cc: mdroth@linux.vnet.ibm.com, agraf@suse.de, qemu-devel@nongnu.org, pbonzini@redhat.com, qemu-ppc@nongnu.org, tyreld@linux.vnet.ibm.com, nfont@linux.vnet.ibm.com, imammedo@redhat.com, afaerber@suse.de --l5oECiFRo5dp+2y7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 30, 2015 at 02:41:50PM +0530, Bharata B Rao wrote: > On Thu, Mar 26, 2015 at 02:44:17PM +1100, David Gibson wrote: > > > +/* > > > + * TODO: Take care of sparsemem configuration ? > > > + */ > > > +static uint64_t numa_node_end(uint32_t nodeid) > > > +{ > > > + uint32_t i =3D 0; > > > + uint64_t addr =3D 0; > > > + > > > + do { > > > + addr +=3D numa_info[i].node_mem; > > > + } while (++i <=3D nodeid); > > > + > > > + return addr; > > > +} > > > + > > > +static uint64_t numa_node_start(uint32_t nodeid) > > > +{ > > > + if (!nodeid) { > > > + return 0; > > > + } else { > > > + return numa_node_end(nodeid - 1); > > > + } > > > +} > > > + > > > +/* > > > + * Given the addr, return the NUMA node to which the address belongs= to. > > > + */ > > > +static uint32_t get_numa_node(uint64_t addr) > > > +{ > > > + uint32_t i; > > > + > > > + for (i =3D 0; i < nb_numa_nodes; i++) { > > > + if ((addr >=3D numa_node_start(i)) && (addr < numa_node_end(= i))) { > > > + return i; > > > + } > > > + } > >=20 > > This function is O(N^2) in number of nodes, which is a bit hideous for > > something so simple. >=20 > Will something like below work ? Will all archs be ok with this ? The below looks like a reasonable idea to me, but it's really the call of the numa and memory subsystem people. Paolo, do you have an opinion? The basic problem here is to have a function which returns which NUMA node a given address lies in. > numa: Store start and end address range of each node in numa_info >=20 > Keep track of start and end address of each NUMA node in numa_info > structure so that lookup of node by address becomes easier. >=20 > Signed-off-by: Bharata B Rao > --- > include/sysemu/numa.h | 3 +++ > numa.c | 28 ++++++++++++++++++++++++++++ > 2 files changed, 31 insertions(+) >=20 > diff --git a/include/sysemu/numa.h b/include/sysemu/numa.h > index 5633b85..6dd6387 100644 > --- a/include/sysemu/numa.h > +++ b/include/sysemu/numa.h > @@ -14,11 +14,14 @@ typedef struct node_info { > DECLARE_BITMAP(node_cpu, MAX_CPUMASK_BITS); > struct HostMemoryBackend *node_memdev; > bool present; > + uint64_t mem_start; > + uint64_t mem_end; I suspect these should be hwaddr, or possible ram_addr_t though. [snip] > > I don't think rtas_ld() should be used outside its intended function > > in rtas. Make a direct call to ldl_phys instead. >=20 > Ok, but @table here is an RTAS arg passed from the main RTAS routine to t= his > function. Still can't use rtas_ld() ? So, rtas_ld() was never intended as a general purpose load function for RTAS use, but specifically for loading arguments from an RTAS style argument list. It's already being used for more than that now in the RTAS code, which I'm not entirely comfortable with. I'd prefer not to extend its use any further. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --l5oECiFRo5dp+2y7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVGgRDAAoJEGw4ysog2bOSokcQAObKnki4Ph9yTEvXQCd+xtq7 1KplVAJdF/EaCLJPMjHSsAH8EDgxiBxawwk66rVBnjLMcJZLASlk86Glm0M4Tr54 Q/u086Y8/zT+q3lKj3yisepoGqKyMrkopD4sXpKY3A9f08SaQUsXduh5uUZZF71f VUfYg22kg3NXhx/nNqDW9iQOhCiLohkDR/MdiXcraEAKWGPgSgoDrTmbKKM4I2fZ HTIpP4n6ZLlPjTnqwsiHdndt4irvM3+XXYzqIV8tATIlpfRTQ5aqlr3BLEFTW2Ct CZutLrBcyhhblaAcAuBuwhvWuNwWKP0wAmm/ABbOSsQWAeU2LQZYi4eYQgHWoOjX tmIvjGMzB9CAY4EuDsTZUHq3+gU63XeBuDNwao3BiwGh88lywwZv5F62Y0nrd0yC u6AFAPkdrMCUq2hfIUyFIlVLqMl+l1+b4Mhpb2ovmp0lzKju9JPCoqwDaGWAgjKB BgtCUYrVSIlZI10z4RNcjy27iO6mnb6rz0fapdw90SK9Qy8S2yX57/bZnOCEIlN5 4LBUrtzy6M3U8ygPHUcJrxk0c0yE3sv2i/7KkCPLHScRYlf8gNECPgLVv0VeTZMk ML8VxlSrQDCTCL7fQTtAjdO8VH3vV6ZwjDp0S6zXeH5pb14Iz6RkDCpUtGQeLUF7 FUyAnzgf5jf9SqjDpVom =NScf -----END PGP SIGNATURE----- --l5oECiFRo5dp+2y7--