From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 1/4] xen: report how much memory a domain has on each NUMA node Date: Wed, 5 Mar 2014 17:31:34 +0100 Message-ID: <1394037094.16409.28.camel@Solace> References: <20140305143357.6984.7729.stgit@Solace> <20140305143625.6984.3763.stgit@Solace> <5317399D.1000001@ts.fujitsu.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7411431004308291174==" Return-path: In-Reply-To: <5317399D.1000001@ts.fujitsu.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Juergen Gross Cc: Ian Campbell , Andrew Cooper , Ian Jackson , xen-devel , Jan Beulich , Daniel De Graaf List-Id: xen-devel@lists.xenproject.org --===============7411431004308291174== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-duVvaBCF+PDx3tg2HArV" --=-duVvaBCF+PDx3tg2HArV Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On mer, 2014-03-05 at 15:50 +0100, Juergen Gross wrote: > On 05.03.2014 15:36, Dario Faggioli wrote: > > diff --git a/xen/common/domctl.c b/xen/common/domctl.c > > index 7cf610a..96bf326 100644 > > --- a/xen/common/domctl.c > > +++ b/xen/common/domctl.c > > @@ -574,6 +574,51 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t= ) u_domctl) > > + spin_lock(&d->page_alloc_lock); > > + page_list_for_each(page, &d->page_list) > > + { > > + node =3D phys_to_nid((paddr_t)page_to_mfn(page) << PAGE_SH= IFT); > > + /* For nodes that are offline, don't touch the counter */ > > + if ( node <=3D max_node_index && node_online(node) ) > > + memkb_on_node[node]++; > > + } >=20 > This loop will run quite a long time for huge domains. Wouldn't it be bet= ter > to do the accounting during page allocation? >=20 Se the reply to Jan (and feel free to chime in, of course. :-P) > > + spin_unlock(&d->page_alloc_lock); > > + > > + for ( node =3D 0; node <=3D max_node_index; node++ ) > > + { > > + memkb_on_node[node] <<=3D (PAGE_SHIFT-10); >=20 > If you already use a 64 bit element you could use bytes as unit. >=20 Yeah, I was trying to be consistent with other calls and interfaces, but there is pretty much everything out there with respect to this: uint32, unsigned int, unsigned long... :-O At least in libxl we have (tools/libxl/libxl_types.idl): # # Specific integer types # MemKB =3D UInt(64, init_val =3D "LIBXL_MEMKB_DEFAULT") And hence: typedef struct libxl_domain_build_info { int max_vcpus; libxl_bitmap avail_vcpus; libxl_bitmap cpumap; libxl_bitmap nodemap; libxl_defbool numa_placement; libxl_tsc_mode tsc_mode; uint64_t max_memkb; uint64_t target_memkb; uint64_t video_memkb; uint64_t shadow_memkb; ... Having looked at this again, I wonder whether sticking to Kbs and switching to uint32 wouldn't be the best solution... > > +/* XEN_DOMCTL_numainfo */ > > +struct xen_domctl_numainfo { > > + /* > > + * IN: maximum addressable entry in the caller-provided arrays. > > + * OUT: minimum between the maximum addressable entry in the > > + * caller-provided arrays and largest online node identifier > > + * in the system. > > + */ > > + uint32_t max_node_index; >=20 > Add explicit padding? >=20 Let's see. As per the reply to Jan, this interface may change. Anyway, I'll do so if it doesn't. Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-duVvaBCF+PDx3tg2HArV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEABECAAYFAlMXUWYACgkQk4XaBE3IOsSuRgCgqthbYwASZnctj3wpGX9I4iX0 necAn1uHwR3RRZvSaX8EM0C1k8nBQuem =6DOR -----END PGP SIGNATURE----- --=-duVvaBCF+PDx3tg2HArV-- --===============7411431004308291174== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7411431004308291174==--