From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: memory hotplug for domUs Date: Wed, 25 Jan 2017 14:02:02 +0100 Message-ID: <1485349322.32103.111.camel@citrix.com> References: <11200980-fff5-3e09-435f-bb0da2ffb219@suse.com> <22658.12973.598314.89177@mariner.uk.xensource.com> <1fdd8185-4270-c1ea-0893-c8d7dd7fae41@suse.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4979275797211765755==" Return-path: Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cWNDL-0006up-59 for xen-devel@lists.xenproject.org; Wed, 25 Jan 2017 13:02:15 +0000 In-Reply-To: <1fdd8185-4270-c1ea-0893-c8d7dd7fae41@suse.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Jim Fehlig , Juergen Gross , Ian Jackson Cc: xen-devel , Wei Liu List-Id: xen-devel@lists.xenproject.org --===============4979275797211765755== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-avs8Iz+fFK1xr2HRSfxP" --=-avs8Iz+fFK1xr2HRSfxP Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2017-01-24 at 16:03 -0700, Jim Fehlig wrote: > On 01/20/2017 09:06 AM, Juergen Gross wrote: > > On 20/01/17 16:54, Ian Jackson wrote: > > > Juergen Gross writes ("memory hotplug for domUs"): > > > > We first thought to enhance "xl mem-set", but after some more > > > > thinking > > > > about it I'd rather add a new xl command, e.g. "mem-add" (we > > > > could later > > > > even add "mem-remove" to support memory unplug). > > >=20 > > > Why ?=C2=A0=C2=A0Why would xl mem-set not automatically do the right = thing > > > ? > >=20 > > How would you specify the numa node to add the memory to? >=20 > And the host numa node providing the memory? >=20 Exactly! I've actually always been a lot confused by all these mem-max, mem-set, set-mem-max, max-set-mem, static-set-mem-max, set-mem-static- max, etc ( :-P ), so I'm not really comfortable giving advices. However, I strongly agree on the fact that this new capability need to be (v)NUMA aware (at least, potentially, for when we'll have complete support for that in all the moving parts). Or we risk having to revisit and potentially change again and re-document the behavior! If a new command is not desirable, can't we add options and parameters to `xl mem-set', and fallback to some well defined default if they're not there ? > > I think it would be clearer with new commands for hotplugging. I > > don't feel very strong about this, so in case everyone else is fine > > with handling everything via mem-set I won't object. >=20 > If ACPI memory hotplug is indeed the goal, then I agree new commands > should be=C2=A0 > used since it is quite different than ballooning. >=20 Yeah, but again, the multiplexing can also happen inside of xl or libxl, basing on parameters, etc. I think the biggest issue here --as in, the thing we're most in lack of right now-- is is to come up with a well defined and well documented behavior, much rather than any technical aspect. FWIW, I'm a bit two minded, as I agree with Juergen and Jim that adding new commands may be cleaner, but I wonder whether having _yet_another_mem_foobar_thing_ would not reveal too confusing and hard to use from a user perspective... Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-avs8Iz+fFK1xr2HRSfxP 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 iQIcBAABCAAGBQJYiKHKAAoJEBZCeImluHPufFUQAIoKvTags+GKA3WLqEG8y8iQ RiiJFfBwqY+7DIjNm5J0WXv+kul8eYiREtC7KOBXTsVlrxMnLiIEj8Dhb5+R6x7e K69tBe+wlhM49xoNFlo78ASevqZg4uHVE4GTnfTag7B08pnTIKr+diq/sUvkz0ru sAVo0OOnj33GldhkjAXVz6GJw1glF8hC5XlG/zu+KaFl0G52SykF7Qbw+Bc9p0MK bvRCSfeZB6oCpwYqWfE04Q98REqwf6k33tiz7Su2BLsE5PCaJV9UdA5oB/zLXoKk /9U7RkDE/igDDsfF2Dpn9boOQktYAWjDbN84XyXWZ7ebbQE6XMHcs6+N0ol85rS5 wI32WVDOalq9JyHW+AFBfxOKcsi6lBg7HmVPMdp7sbCU9IEGdpQe7DdPISuR2YlT nt6tLBMN63zEYhZvC+hjGVRrggGtk+ByYWRjM+2UhizbJTH+EDp63DRw2f3B1gHB jOwlVELk8iTQ0Ju5bT7g++6cxM1AessoKxAz761QB7bTOZlw5+5rS9CL8IEM6Q/7 icxql0eottFwoLWwWmSDIbnvOm7G2tfujAfJ4jXRjimFJQnM/4SywfZSOAobOBVS 8vHo28h7oDTwpUCg4gl8KphxwEvf5c1gRXTFkcvbieQdxGaTpAHwEV0oUb+1Lwa4 WrEQq6615k1znnu6XVfP =xRja -----END PGP SIGNATURE----- --=-avs8Iz+fFK1xr2HRSfxP-- --===============4979275797211765755== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============4979275797211765755==--