Re: [PATCH] x86: fix memory cut-off when using PFN compression

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1542 bytes --]

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.
> 
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

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel