Re: [Xen-devel] Proposed XENMEM_claim_pages hypercall: Analysis of problem and alternate solutions

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 14/01/13 18:18, Dan Magenheimer wrote:
> > > > > i.e. d->max_pages is fixed for the life of the domain and
> > > > > only d->tot_pages varies; i.e. no intelligence is required
> > > > > in the toolstack.  AFAIK, the distinction between current_maxmem
> > > > > and lifetime_maxmem was added for Citrix DMC support.
[snip]
> Yes, understood.  Ian please correct me if I am wrong, but I believe
> your proposal (at least as last stated) does indeed, in some cases,
> set d->max_pages less than or equal to d->tot_pages.  So AFAICT the
> change does very much have a bearing on the discussion here.
Strictly speaking, no, it doesn't have to do with what we're proposing.  
To impement "limit-and-check", you only need to set d->max_pages to 
d->tot_pages.  This capability has been possible for quite a while, and 
was not introduced to support Citrix's DMC.
> Exactly.  So, in your/Ian's model, you are artificially constraining a
> guest's memory growth, including any dynamic allocations*.  If, by bad luck,
> you do that at a moment when the guest was growing and is very much in
> need of that additional memory, the guest may now swapstorm or OOM, and
> the toolstack has seriously impacted a running guest.  Oracle considers
> this both unacceptable and unnecessary.
Yes, I realized the limitation to dynamic allocation from my discussion 
with Konrad.  This is a constraint, but it can be worked around.
Even so you rather overstate your case.  Even in the "reservation 
hypercall" model, if after the "reservation" there's not enough memory 
for the guest to grow, the same thing will happen.  If Oracle really 
considered this "unacceptable and unnecessary", then the toolstack 
should have a model of when this is likely to happen and keep memory 
around for such a contingency.
> So, I think it is very fair (not snide) to point out that a change was
> made to the hypervisor to accommodate your/Ian's memory-management model,
> a change that Oracle considers unnecessary, a change explicitly
> supporting your/Ian's model, which is a model that has not been
> implemented in open source and has no clear (let alone proven) policy
> to guide it.  Yet you wish to block a minor hypervisor change which
> is needed to accommodate Oracle's shipping memory-management model?
We've been over this a number of times, but let me say it again. Whether 
a change gets accepted has nothing to do with who suggested it, but 
whether the person suggesting it can convince the community that it's 
worthwhile.  Fujitsu-Seimens implemented cpupools, which is a fairly 
invasive patch, in order to support their own business models; while the 
XenClient team has had a lot of resistance to getting v4v upstreamed, 
even though their product depends on it.  My max_pages change was 
accepted (along with many others), but many others have also been 
rejected.  For example, my "domain runstates" patch was rejected, and is 
still being carried in the XenServer patchqueue several years later.
If you have been unable to convince the community that your patch is 
necessary, then either:
1. It's not necessary / not ready in its current state
2. You're not very good at being persuasive
3. We're too closed-minded / biased whatever to understand it

You clearly believe #3 -- you began by accusing us of being 
closed-minded (i.e., "stuck in a static world", &c), but have since 
changed to accusing us of being biased.  You have now made this 
accusation several times, in spite of being presented evidence to the 
contrary each time.  This evidence has included important Citrix patches 
that have been rejected, patches from other organizations that have been 
accepted, and also evidence that most of the people opposing your patch 
(including Jan, IanC, IanJ, Keir, Tim, and Andres) don't know anything 
about DMC and have no direct connection with XenServer.
For my part, I'm willing to believe #2, which is why I suggested that 
you ask someone else to take up the cause, and why I am glad that Konrad 
has joined the discussion.
 -George

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