[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

> From: George Dunlap [mailto:George.Dunlap@xxxxxxxxxxxxx]
>    :
> No, it does not.
>    :
> No, it does not.
>    :
> We don't need this new hypercall.  You should just fix your own bugs
> rather than introducing new hacks to work around them.

Ouch.  I'm sorry if the previous discussion on this made you angry.
I wasn't sure if you were just absorbing the new information or
rejecting it or just too busy to reply, so decided to proceed with
a more specific proposal.  I wasn't intending to cut off the

New paradigms and paradigm shifts always encounter resistance,
especially from those with a lot of investment in the old paradigm.

This "new" paradigm, tmem, has been in Xen for years now and the
final piece is now in upstream Linux as well.  Tmem is in many ways
a breakthrough in virtualized memory management, though admittedly
it is far from perfect (and, notably, will not help proprietary
or legacy guests).

I would hope you, as release manager, would either try to understand
the different paradigm or at least accept that there are different
paradigms than yours that can co-exist in an open source project.

To answer some of your points:

Dynamic handling of memory management is not a bug.  And selfballooning
is only a small (though important) part of the tmem story.  And
the Oracle "toolstack" manages hundreds of physical machines and
thousands of virtual machines across a physical network, not one
physical machine with a handful of virtual machines across Xenbus.
So we come from different perspectives.

As repeatedly pointed out (and confirmed by others), variations
of the memory "race" problem exist even without tmem.  I do agree
that if a toolstack insists that only it, the toolstack, can ever
allocate or free memory, the problem goes away.  You think that
restriction is reasonable, and I think it is not.

The "claim" proposal is very simple and (as far as I can tell so far)
shouldn't interfere with your paradigm.  Reinforcing your paradigm
by rejecting the proposal only cripples my paradigm.  Please ensure
you don't reject a proposal simply because you have a different


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.