[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Please ack XENMEM_claim_pages hypercall?
> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |