From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37127) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aw2BT-0007EH-2d for qemu-devel@nongnu.org; Fri, 29 Apr 2016 02:45:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aw2BP-0006At-Te for qemu-devel@nongnu.org; Fri, 29 Apr 2016 02:45:51 -0400 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> <20160425112050.545f4ff3@nial.brq.redhat.com> <20160426050923.GB9793@in.ibm.com> <20160426095236.23e51b77@nial.brq.redhat.com> <20160426210337.11723.83860@loki> <20160429032403.GA3010@littlecatz.fritz.box> From: Thomas Huth Message-ID: <57230311.1060200@redhat.com> Date: Fri, 29 Apr 2016 08:45:37 +0200 MIME-Version: 1.0 In-Reply-To: <20160429032403.GA3010@littlecatz.fritz.box> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J2WAw3V80wUXPmnoIBj0WMhMnuHjtRcpL" 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: David Gibson , Michael Roth Cc: Igor Mammedov , Bharata B Rao , qemu-devel@nongnu.org, qemu-ppc@nongnu.org, nfont@linux.vnet.ibm.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --J2WAw3V80wUXPmnoIBj0WMhMnuHjtRcpL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 29.04.2016 05:24, David Gibson wrote: > On Tue, Apr 26, 2016 at 04:03:37PM -0500, Michael Roth wrote: =2E.. >> In the case of pseries, the DIMM abstraction isn't really exposed to >> the guest, but rather the memory blocks we use to make the backing >> memdev memory available to the guest. During unplug, the guest >> completely releases these blocks back to QEMU, and if it can only >> release a subset of what's requested it does not attempt to recover. >> We can potentially change that behavior on the guest side, since >> partially-freed DIMMs aren't currently useful on the host-side... >> >> But, in the case of pseries, I wonder if it makes sense to maybe go >> ahead and MADV_DONTNEED the ranges backing these released blocks so th= e >> host can at least partially reclaim the memory from a partially >> unplugged DIMM? >=20 > Urgh.. I can see the benefit, but I'm a bit uneasy about making the > DIMM semantics different in this way on Power. >=20 > I'm shoehorning the PAPR DR memory mechanism into the qemu DIMM model > was a good idea after all. Ignorant question (sorry, I really don't have much experience yet here): Could we maybe align the size of the LMBs with the size of the DIMMs? E.g. make the LMBs bigger or the DIMMs smaller, so that they match? Thomas --J2WAw3V80wUXPmnoIBj0WMhMnuHjtRcpL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJXIwMVAAoJEC7Z13T+cC21/X8P/2CSehfQ1feMiCoDY2iGfXLa nuNNSCZsqPyELIe0OxN6VfQ6QbDRND45xQv2s1k6cib2rA4QZzFQAGvVwb2hebEu Cc4Akx9LCNq35mvABtdKot9YHXlwMBN6QLxOlCb9GXxfHFtQ/WY51iqlnZkHZ067 IdlFxjk64SwEXMqw856jaSpsoxJGBWVpAuzle8BNHw3I/jsDQ7Kh7GXRAb09hgaz XxQREIvbTwJDmxwgL8sX4IubddaKCgKv0os05uyr32h5rpEnqqdmLIme4QVbC1k1 BkjHkFz2jaZ7BcSuqdT+UWZPN1oNJDsugrjyfokpNEiGYsVT8fB9D/ZAvfM0uMWq o4Jfy+GzieNWqC5ddehebWCszsG8WP2o8kjUaD+3XDecUBmoH5sYYIW8PvIkOQa5 5UhCoSSGuQKvdsGoclQ4KMTrlRO31HzBqYAisTMauFElGuhmG3E4kTid3a5pgTQR Nsl7+T53mx0FnnUb8wWNAER9Ii7nrW8ciqF7Jy4Abd5eHgbcRbEFCInXcyIg6yIb nM2KV/53SPYPgwNGU51xOo2S0OQ5ohSKGtcACuC3o8eWbSrU13eMjgv06assNPPX jGJSf8ddp/r0tqouwaUB1jXJd9xUjLey81Nnd7yi9v//lF73vRxy4B0A41+MF3bO En/+A6GTvSqby5y+47tP =Wlhz -----END PGP SIGNATURE----- --J2WAw3V80wUXPmnoIBj0WMhMnuHjtRcpL--