From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v3 ]libxl: allow to set more than 31 vcpus Date: Fri, 01 Jun 2012 10:44:39 +0200 Message-ID: <1338540279.31901.17.camel@Abyss> References: <1338532541.31901.10.camel@Abyss> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0698720075193277151==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Zhang, Yang Z" Cc: "xen-devel@lists.xensource.com" , Ian Campbell List-Id: xen-devel@lists.xenproject.org --===============0698720075193277151== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-1/PL893DS8ZKfdo9M+oe" --=-1/PL893DS8ZKfdo9M+oe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2012-06-01 at 07:18 +0000, Zhang, Yang Z wrote:=20 > > > diff -r 3b0eed731020 tools/libxl/xl_cmdimpl.c > > > --- a/tools/libxl/xl_cmdimpl.c Fri Jun 01 09:27:17 2012 +0800 > > > +++ b/tools/libxl/xl_cmdimpl.c Fri Jun 01 10:34:13 2012 +0800 > > > @@ -650,7 +650,14 @@ static void parse_config_data(const char > > > > > > if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) { > > > b_info->max_vcpus =3D l; > > > - b_info->cur_vcpus =3D (1 << l) - 1; > > > + > > > + if (libxl_cpumap_alloc(ctx, &b_info->avail_vcpus, l)) { > > > + fprintf(stderr, "Unable to allocate cpumap\n"); > > > + exit(1); > > > + } > > > > > ... Do you mind explaining me what would have happened here without you= r > > previous patch, i.e., by just using the existing libxl_cpumap_alloc ? > > > > I might be wrong, but I was wondering whether it is worth changing the > > interface like that for just this single case which saves, what, 1 to 3 > > bytes per domain? > >=20 >=20 > It's ok to use existing libxl_cpumap_alloc(). But in my case, there is no= need to use the existing interface. > Ok. > And, in future, there are some cases may not need to allocate max size cp= umap too > So it's better to extend the current interface. >=20 Well, maybe... Who knows what future reserves ?!? :-D Anyway, although I see your point, I really really dislike the new parameter in libxl_cpumap_alloc(), but of course it is not something up to me to decide, neither it is something I'd loose some sleep for. :-P Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-1/PL893DS8ZKfdo9M+oe 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 v1.4.12 (GNU/Linux) iEYEABECAAYFAk/IgPcACgkQk4XaBE3IOsQvjgCgkac9C6GvYeL7BfovxiyIrlO/ o1QAnifY1Fi+s6fdlngClXyzB9qDxIsP =rKrF -----END PGP SIGNATURE----- --=-1/PL893DS8ZKfdo9M+oe-- --===============0698720075193277151== 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 --===============0698720075193277151==--