From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael R. Hines" Subject: physmap deallocation on balloon? Date: Tue, 08 Apr 2008 20:39:10 -0400 Message-ID: <47FC102E.500@cs.binghamton.edu> Reply-To: mhines@cs.binghamton.edu Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1287949315==" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1287949315== Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=------------enig656C5CA1A163819F7EA4B54B This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig656C5CA1A163819F7EA4B54B Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Greetings, Currently, as I understand PV memory allocation, the Guest's pfn -> mfn physmap will get populated on-demand as the guest uses more an more of its memory reservation. Is it possible to also make this go in the reverse direction? For example: let's say we have a guest that is mostly idle and has a great deal of free memory and we decide to balloon down the domain. In addition to decreasing the domain's reservation, is it also possible to remove the physmap entries in an on-demand fashion as memory is freed up? --=20 /* Michael R. Hines http://www.cs.binghamton.edu/~mhines/ Live long and prosper... */ --------------enig656C5CA1A163819F7EA4B54B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFH/BAu5CdHxppqAIYRAuz9AJ0ZSvxERAoipV5EEC0hTXPR6WG2EgCbBl7Y tPBCJSsfJHgxKmxIoW3VbFg= =XuK+ -----END PGP SIGNATURE----- --------------enig656C5CA1A163819F7EA4B54B-- --===============1287949315== 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.xensource.com http://lists.xensource.com/xen-devel --===============1287949315==--