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

Re: [Xen-devel] [PATCH v3 1/3] libxl: xl mem-max et consortes must update static-max in xenstore too [and 1 more messages]



On Tue, Apr 16, 2013 at 01:21:46PM +0100, Ian Campbell wrote:
> On Tue, 2013-04-16 at 13:10 +0100, Daniel Kiper wrote:
> > Ian, any additional thoughts, comments, ...?
>
> Do you mean me or IanJ?

You, but if IanJ has comments I am happy to hear them too...

> I think I'm still of the opinion that operations which may involve
> memory hotplug on the guest side rather than just ballooning should be
> explicit, at least at the libxl API layer. TBH I'm not sure what this
> would look like since the current API doesn't really seem to suggest a
> natural way to extend it like this.
>
> At the xl layer I'm not so sure what the answer is but xl is easier to
> change if we aren't happy with it.

I think that we should not care (from a host point of view) which mechanism
is used in a guest to increase its memory size. From the host point of view
in balloon case and in memory hotplug case we just allocate pages for the guest.
We do not care where they will be placed and when they will be used. That is it.

However, we should create a mechanism which allows the guest to allocate memory
above limit set at boot and not eat all host memory in uncontrolled manner
(e.g. using memory hotplug mechanism). Last is provided by xl now but former
is not. Currently there is no way to increase memory limit above memory limit
set at boot (maxmem). Now I think we should just decide which value should be
used as a cap reference: static-max or "xen maximum". Both are not perfect
and some recalculation is always needed to establish real cap internaly
in the guest.

Daniel

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


 


Rackspace

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