[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |