From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH] x86: fix memory cut-off when using PFN compression Date: Wed, 11 Sep 2013 16:02:44 +0200 Message-ID: <1378908164.2821.117.camel@Solace> References: <523082A302000078000F26E0@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1632381942266265421==" Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VJl47-00021T-F2 for xen-devel@lists.xenproject.org; Wed, 11 Sep 2013 14:06:43 +0000 In-Reply-To: <523082A302000078000F26E0@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , Keir Fraser List-Id: xen-devel@lists.xenproject.org --===============1632381942266265421== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-QbBAI7zXk/mD30CIYsiV" --=-QbBAI7zXk/mD30CIYsiV Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On mer, 2013-09-11 at 13:48 +0100, Jan Beulich wrote: > The only possibly problematic consumer of node_spanned_pages (the > meaning of which gets altered here in that it now also includes memory > Xen can't actively make use of) is XEN_SYSCTL_numainfo: At a first > glance the potentially larger reported memory size shouldn't confuse > tool stacks. >=20 It really shouldn't... Just one thing (if you happen to know that from the top of you head): would this "potentially larger" amount of pages being reported involve only what XEN_SYSCTL_numainfo reports as the node's size (which indeed uses node_spanned_pages() ), or would it also affect what it reports as the amount of free memory on the node (which uses avail_node_heap_pages() ) ? I tried to find that out by myself and I'd say that is not the case (i.e., amount of free memory is not affected), as I did not fine any call to node_spanned_pages()... Did I miss anything? The reason why I'm asking is that, while the nodes' size is not something that anyone really consumes, the amount of free memory in each node is utilized b the automatic NUMA placement algorithm, and I'm trying to figure out whether this potential larger page reporting could be an issue there. Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-QbBAI7zXk/mD30CIYsiV 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 v1.4.14 (GNU/Linux) iEYEABECAAYFAlIweAQACgkQk4XaBE3IOsSeUQCeOpuKCBQP58KS3bGQE1M7IU28 ZLcAniKAt67pD+L2s8v426Zd0phW8ETr =zEtu -----END PGP SIGNATURE----- --=-QbBAI7zXk/mD30CIYsiV-- --===============1632381942266265421== 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.xen.org http://lists.xen.org/xen-devel --===============1632381942266265421==--