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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

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

Jan


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