Re: [Xen-devel] Proposed new "memory capacity claim" hypercall/feature

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Mon, Oct 29, 2012 at 6:06 PM, Dan Magenheimer
<dan.magenheimer@xxxxxxxxxx> wrote:
> Keir, Jan (et al) --
>
> In a recent long thread [1], there was a great deal of discussion
> about the possible need for a "memory reservation" hypercall.
> While there was some confusion due to the two worldviews of static
> vs dynamic management of physical memory capacity, one worldview
> definitely has a requirement for this new capability.

No, it does not.


> I'm not just arguing against reservation-as-a-toolstack-mechanism,
> I'm stating I believe unequivocally that reservation-as-a-toolstack-
> only-mechanism and tmem are incompatible.  (Well, not _totally_
> incompatible... the existing workaround, tmem freeze/thaw, works
> but is also single-threaded and has fairly severe unnecessary
> performance repercussions.  So I'd like to solve both problems
> at the same time.)

No, it is not.

Look, the *only* reason you have this problem is that *you yourselves*
programmed in two incompatible assumptions:

1. You have a toolstack that assumes it can ask "how much free memory
is there" from the HV and have that be an accurate answer, rather than
keeping track of this itself

2. You wrote the tmem code to do "self-ballooning", which for no good
reason, gives memory back to the hypervisor, rather than just keeping
it itself.

Basically #2 breaks the assumption of #1.  It has absolutely nothing
at all to do with tmem.  It's just a quirk of your particular
implementation of self-ballooning.

This new hypercall you're introducing is just a hack to fix the fact
that you've baked in incompatible assumptions.  It's completely
unnecessary.  All of the functionality you're describing can be
implemented outside of the hypervisor in the toolstack -- this would
fix #1.  Doing that would have no effect on tmem whatsoever.

Alternately, you could fix #2 -- have the "self-ballooning" mechanism
just allocate the memory to force the swapping to happen, but *not
hand it back to the hypervisor*.

We don't need this new hypercall.  You should just fix your own bugs
rather than introducing new hacks to work around them.

 -George

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