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

Re: [Xen-devel] initial ballooning amount on HVM+PoD



On Mon, 2014-01-20 at 08:08 +0000, Jan Beulich wrote:
> >>> On 17.01.14 at 18:13, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > On Fri, 2014-01-17 at 14:33 +0000, Jan Beulich wrote:
> >> Interestingly, (a) too results in the driver not ballooning down
> >> enough - there's a gap of exactly as many pages as are marked
> >> reserved below the 1Mb boundary. Therefore aforementioned
> >> upstream commit is presumably broken.
> > 
> > Can we count those reserved pages? (I guess you mean reserved in the
> > e820?)
> 
> Yes, we could. But it's not logical to count the ones below 1Mb, but
> not the ones above.

I can understand that PoV but it's not like the PC architecture isn't
full of weird quirks and assumptions which are specific to the low
1Mb...

>  Yet we can't (without knowledge of the tools/
> firmware implementation) tell regions backed by RAM assigned to the
> guest (e.g. the reserved pages below 1Mb, covering BIOS stuff)
> from regions reserved for other reasons. A specific firmware could,
> for example, have a larger BIOS region right below 4Gb (like many
> non-virtual BIOSes do), which would then also be RAM covered and
> hence also need accounting.

Couldn't this be accounted for in the toolstack when considering the
target and max_pages? But I suppose it is too late for that now if you
want to DTRT on existing systems.

> >> Short of a reliable (and ideally architecture independent) way of
> >> knowing the necessary adjustment value, the next best solution
> >> (not ballooning down too little, but also not ballooning down much
> >> more than necessary) turns out to be using the minimum of (b)
> >> and (c): When the domain only has memory below 4Gb, (b) is
> >> more precise, whereas in the other cases (c) gets closest.
> > 
> > I think I'd prefer an arch specific calculation (or an arch specific
> > adjustment to a generic calculation) to either of the above.
> 
> Hmm, interesting. I would have expected a generic calculation to
> be deemed preferable.

Yes, I'd much prefer an accurate per-arch calculation to a generic fudge
which only gets close for everyone.

Ian.


_______________________________________________
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®.