Re: [Xen-devel] Please ack XENMEM_claim_pages hypercall?

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxx]
> Sent: Tuesday, November 27, 2012 3:32 AM
> To: Jan Beulich
> Cc: Dan Magenheimer; George Dunlap; Ian Jackson; xen-devel@xxxxxxxxxxxxx; 
> Konrad Wilk; Zhigang Wang;
> Keir (Xen.org); Tim (Xen.org)
> Subject: Re: Please ack XENMEM_claim_pages hypercall?

Hi Ian --
 
> I'm also a little surprised that this patch is being so aggressively
> pushed upstream when the toolstack work which would use it is seemingly
> not fully formed yet.

The deficiency in the Oracle toolstack has been known for years
and this solution has been discussed and approved at the VP level.
 
> Anyway, it seems to me that this argument seems to me to be starting
> from the wrong end, it starts from the hypercall and tries to justify it
> based on requirements imposed by an toolstack which is presented as
> something of a fixed black box from the xen-devel point of view, which
> is not something I find particularly convincing.

I fully recognize that the existence of the black box is annoying.
But the argument began not with a hypercall but with a real
customer problem.  The early discussion, in which others suggested
"change your toolstack", uncovered a rather dramatic paradigm
difference that re-emphasized the need for the hypercall.
See below.

> So a possible alternative to Oracle carrying this patch long term is
> that someone who understands Oracle's toolstack's requirements and
> constraints takes over from Dan (who I think has said several times that
> he is not familiar with all the details of the Oracle toolstack) as
> advocate for finding a solution to the underlying issue here and can
> engage xen-devel in a discussion about the design decisions involved
> from the toolstack downwards. Either this leads to the proposed solution
> in the hypervisor (or something similar) or it results in a completely
> different solution which everyone is happy with (or I suppose it might
> still end up with Oracle carrying this patch long term).

>From a single-system-xl-toolstack-centric perspective ("paradigm"),
I can see your point.  This is not an xl-toolstack-centric problem.

> I also feel I should also point out that contrary to the claims in
> http://lists.xen.org/archives/html/xen-devel/2012-11/msg01427.html and
> elsewhere the acceptance or otherwise of this patch has nothing to do
> with Citrix. Although some of the folks involved in the discussion are
> employed by Citrix they are all members of the "platform team" which
> operates independently, is concerned with the state of Xen.org provided
> Xen bits and is not tied to any product team (Citrix or otherwise). So
> this has nothing whatsoever to do with Citrix's plans to use this
> mechanism (and such conspiracy theories IMHO add nothing to the
> discussion). AFAIK no one who is involved with any of Citrix's products
> has said anything at all in any thread on the matter one way or the
> other.

Conspiracy theory?  Some old guy from your neck of the woods said
something like: "Methinks, the maintainer doth protest too much." ;-)

I apologize if my words have implied that maintainers employed
by Citrix are intentionally making decisions that favor Citrix.
I _am_ implying, however, that the single-system-inference/policy-driven
memory-load-balancer paradigm _has_ influenced the open source
hypervisor _and_ heavily influenced the objections to this proposal.
AFAIK, Citrix's Dynamic Memory Controller (DMC) in XenServer is
the only shipping example (in the Xen universe) of that, so I call
it the "Citrix paradigm".  Xen decisions made with this paradigm
in mind heavily favor a single-system model, which lead to
solutions to problems which are not as applicable to a data-center
paradigm such as Oracle's.  I _do_ consider this a serious issue
and suggest that the maintainers consider it deeply because
the hypervisor must serve both paradigms.

Now, with that in mind, I still haven't heard any objections
other than insufficient testing (fair, but also very true of
most patches accepted into xen-unstable months before a release);
and "your toolstack should use the 'Citrix paradigm'" (and
I believe I have adequately explained why we cannot).  Are
there other valid objections?

Thanks,
Dan

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