From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52030) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiZkl-0008Fq-7t for qemu-devel@nongnu.org; Tue, 22 Mar 2016 23:46:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aiZkh-00070O-78 for qemu-devel@nongnu.org; Tue, 22 Mar 2016 23:46:39 -0400 Date: Wed, 23 Mar 2016 14:22:30 +1100 From: David Gibson Message-ID: <20160323032230.GU23586@voom.redhat.com> References: <1458016736-10544-1-git-send-email-bharata@linux.vnet.ibm.com> <1458016736-10544-3-git-send-email-bharata@linux.vnet.ibm.com> <20160316013605.GC9032@voom> <20160316044154.GD13176@in.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nk27jClX7wGPY2hW" Content-Disposition: inline In-Reply-To: <20160316044154.GD13176@in.ibm.com> Subject: Re: [Qemu-devel] [RFC PATCH v2 2/2] spapr: Memory hot-unplug support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bharata B Rao Cc: thuth@redhat.com, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com, qemu-ppc@nongnu.org, nfont@linux.vnet.ibm.com, imammedo@redhat.com --nk27jClX7wGPY2hW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 16, 2016 at 10:11:54AM +0530, Bharata B Rao wrote: > On Wed, Mar 16, 2016 at 12:36:05PM +1100, David Gibson wrote: > > On Tue, Mar 15, 2016 at 10:08:56AM +0530, Bharata B Rao wrote: > > > Add support to hot remove pc-dimm memory devices. > > >=20 > > > Signed-off-by: Bharata B Rao > >=20 > > Reviewed-by: David Gibson > >=20 > > Looks correct, but again, needs to wait on the PAPR change. > >=20 > > Have you thought any further on the idea of sending an index message, > > then a count message as an interim approach to fixing this without > > requiring a PAPR change? >=20 > Removal by index and removal by count are valid messages by themselves > and drmgr would go ahead and start the removal in reponse to those > calls. IIUC, you are suggesting that lets remove one LMB by index in > response to 1st message and remove (count -1) LMBs from where the last > removal was done in the previous message. Yes, that's the idea. > Since the same code base of powerpc-utils works on PowerVM too, I am not > sure if such an approach would impact PowerVM in any undesirable manner. > May be Nathan can clarify ? Heard anything from Nathan? I don't really see how it would be bad under PowerVM. Under PowerVM it generally doesn't matter which LMBs you remove, right? So removing the ones immediately after the last one you removed should be as good a choice as any. > I see that this can be done, but the changes in drmgr code specially the > code related to LMB list handling/removal can be non-trivial. So not sure > if the temporary approach is all that worth here and hence I feel it is b= etter > to wait and do it the count-indexed way. Really? drmgr is already scanning LMBs to find ones it can remove. Seeding that scan with the last removed LMB shouldn't be too hard. > While we are here, I would also like to get some opinion on the real > need for memory unplug. Is there anything that memory unplug gives us > which memory ballooning (shrinking mem via ballooning) can't give ? Hmm.. that's an interesting question. =20 --=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 --nk27jClX7wGPY2hW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJW8gv2AAoJEGw4ysog2bOShWAQAOZgwZ3xb8Q7VRp2fSc+hFhH f3DQv7ZCGqCWqNTFC1wM4TzYmIs9bPqH1CeSMZ+g62CMpRAh9/d3PWobO8NfrxlN QF+4R36q7xucm3hntym3K+yPfKO+tHtXqY05UsQOSL576q3cgkE2KzK+4j6uUVuj IvwWq5NabBKmdSgimV/k1X+boQR+oOKWfOT2BrEWRsdbNIRI5tPOqD/IHrrnB8LV H7o7fXmfVJslJvFMk+Oqt7gqa5qosovqn7Pbez6PiXMdPJFSsJgbuNR00HopBswp pc/1P8iPPnYu2CEiM2YHQZOQJB2yzNPtyrUh+bgZuojhBAenfq09BiXDcGR7tASS lbrTkZbV+NmMuQbVhbzQQgY+GGS3VZpMtuS3gQ16oRv6Euqx9k37fDOPLHLUep4O k4hO0Pcmr56hOT6wmZO5j9feJksjBnIcvbFl6vFaAACuKWFiSt9xz6ciXaL+sCJh TVhAZQ902doC15OnvvvFJeKJ3l0uNrmX7AKRqXzLSGM7rwyD1ztJHQ8m91aG6H3K YElHexolnbArjSnWAwGmewhbk7bYJ0PhkBmpg8zKyq4LE6LI1aQmVo1sBOW/Qn9l VgW145aeVaCG5w/+h3vF5mggGExUXh9zdt4nYf2Eus3XWyBM1BTemHxsr/eGq4qX LlZNXjnkhjCAcIQzU3IM =VGG3 -----END PGP SIGNATURE----- --nk27jClX7wGPY2hW--