On Mon, Nov 10, 2014 at 11:51:28AM +0100, Dario Faggioli wrote:
On Mon, 2014-11-10 at 10:00 +, Wei Liu wrote:
On Mon, Nov 10, 2014 at 09:21:24AM +, Jan Beulich wrote:
On 08.11.14 at 20:43, wei.l...@citrix.com wrote:
This information is passed in in domctl hypercall but the guest
interface doesn't expose it to guest. PV NUMA-aware ballooning relies on
this piece of information to function properly.
Considering that exposing this mapping is wrong from a conceptual
pov (as was discussed during the review of Elena's original series),
the desire to nevertheless expose it would need to be explained
much better than what you did above.
My thought was that if a PV guest needs to do NUMA-aware ballooning, it
would be easier to have the mapping at hand to let the guest request
explicitly from what physical node it wants the page. It was based
on my vague memory of early version of Elena's series.
Some discussion on this happened while talking about some early work on
NUMA-aware ballooning. This is a message from that thread:
http://lists.xenproject.org/archives/html/xen-devel/2013-08/msg01986.html
Phew! That's a year ago. No wonder I don't remember anything...
However, if this is conceptually wrong and has been discussed before,
(as I said in the other email) please just ignore this patch. I can try
to modify the hypervisor instead to make NUMA-aware ballooning happen
under the hood without guest knowing anything. That is, to make use of
the vmemrange structure to identify the vnode of a particular gpfn, then
with vnode_to_pnode map to identify the physical node of that gpfn, then
do NUMA-aware ballooning.
I'm all for *not* exposing such information to the guest. However, a
quote from George, from that thread, with which I *totally* agree with,
is this one:
I would like to point out that to make this [NUMA aware ballooning]
work for ballooning *up*, however, there will need to be a way for the
guest to specify, please allocate from vnode X, and have Xen
translate the vnode into the appropriate pnode(s).
If this can be done without exposing the mapping, as Wei suggests, then
I agree we should go for it. If not, we'll have to introduce something
like this (along with proper documentation of how it should be used) at
some point.
I'm 100% ok to re-start that discussion here and now... however, how
stable should this interface be? Can't we deal with this when actually
implementing NUMA aware ballooning and add stuff at than point, if
necessary?
The risk would be any new guests with extended get_vnumainfo interface
won't be able to run on old hypervisor (4.5) without proper versioning.
So basically we have three choices:
1. Expose vnode_to_pnode in hypercall interface.
2. Expose the mapping in xenstore.
3. Don't expose anything, everything happens automagically without guest
knowing anything.
I'm fine with any of those three. However, Jan suggested in that one
year old thread it would be wrong for the guest to know the mapping, so
I think he implicitly voted for the third option.
I only need to make sure that we don't miss option 1 and release
incomplete interface for 4.5. That's why I kick off this discussion. If
we release the interface as it is now and find out we need to expose
mapping later, we would neither 1) do versioning 2) have yet another
interface to return mapping.
Wei.
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 RD Ltd., Cambridge (UK)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
