From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: [PATCH v9 3/3] tools/libxc: use superpages during restore of HVM guest Date: Wed, 6 Sep 2017 14:24:28 +0200 Message-ID: <20170906122428.GD23062@aepfle.de> References: <20170901160843.9057-1-olaf@aepfle.de> <20170901160843.9057-4-olaf@aepfle.de> <44beb406-8640-7c1c-7f76-f534e37aa2b8@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5816646539591886531==" Return-path: In-Reply-To: <44beb406-8640-7c1c-7f76-f534e37aa2b8@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Andrew Cooper Cc: Wei Liu , Ian Jackson , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============5816646539591886531== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bajzpZikUji1w+G9" Content-Disposition: inline --bajzpZikUji1w+G9 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On Wed, Sep 06, Andrew Cooper wrote: > I still fail to understand why you need the bitmaps at all? You can > calculate everything you need from the pfn list alone, which will also > let you spot the presence or absence of the VGA hole. These bitmaps track if a range has been allocated as superpage or not. If there is a given pfn within a range of either 1G or 2M there might be double allocation of a 1G or 2M page. This is not related to the VGA hole. These two lines are just hints that in this range no superpage can be allocated. > You need to track which pfns you've see so far in the stream, and which > pfns have been populated. When you find holes in the pfns in the > stream, you need to undo the prospective superpage allocation. Unless > I've missed something? This is whats happening, holes will be created as soon as they are seen in the stream. > Also, please take care to use 2M decrease reservations wherever > possible, or you will end up shattering the host superpage as part of > trying to remove the memory. This is what Wei suggested, build a list of pfns instead of releasing each pfn individually. I think with this new code it should be possible to decrease in 2M steps as needed. Olaf --bajzpZikUji1w+G9 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSkRyP6Rn//f03pRUBdQqD6ppg2fgUCWa/o/AAKCRBdQqD6ppg2 flzoAJ9RNUk/CJV5aRVZ5tkruHVNtodSHQCfRInQvclt8Jw1CUMf4Sp41JNzMtM= =zoak -----END PGP SIGNATURE----- --bajzpZikUji1w+G9-- --===============5816646539591886531== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============5816646539591886531==--