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

Re: [Xen-devel] dom0 not seeing all of the assigned memory

Am 15.03.2012 19:54, schrieb David Vrabel:
> On 15/03/12 18:33, Konrad Rzeszutek Wilk wrote:
>> On Sun, Mar 11, 2012 at 11:20:02PM +0100, Sven Köhler wrote:
>>> I have the same problem. I believe this also happens even if the
>>> ballooning driver is disabled in dom0 kernel.
> Well, yes.  The balloon driver needs to be enabled and a new target set
> to get back the memory released during boot.

The dom0 releases pages and passes them back to the hypervisor?
But why does it do so in the first place?

>>>> Make sure you have added the following patch to your Xen if you are
>>>> using a recent >=3.1 kernel. Unfortunately it isn't in Xen 4.1.x, but
>>>> I guess it should be added to there:
>>>> http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c56dd5eb0fa2
>>>> See if it helps.
>>> I recompiled the hypervisor (this was a patch for the hypervisor,
>>> right?) and dom0 only has around 413MB inspite of dom0_mem=512M
>>> hypervisor parameter.
> You need dom0_mem=max:512M

I can't find documentation on what that does. But if I had to make an
educated guess, I would assume that dom0_mem=max:512M sets an upper
bound on the memory that dom0 may consume. It sounds like, the
hypervisor may take memory away from dom0, so that dom0 drops below the
specified 512MB.

Here's what I want to do (and what I though that dom0_mem=512M would
actually do): I want dom0 to have _exactly_ 512MB of RAM. Neither less
nor more than that.

So what does dom0_mem=512M do? Does it set a lower bound?
Recommendation for dom0_mem=512M are all over the internet (even
wiki.xen.org) and it is often explained as statically assinging memory
to dom0 (which IMHO implies that 512M is both the upper and lower bound).

>>> free shows 413MB straight after booting into dom0 (no xend, xenstored or
>>> anything xen related stuff has started yet).
> This case isn't because of the released memory (since 512M is well below
> the MMIO holes that cause lots of released memory) but because page
> tables are reserved to the amount of physical ram in the system.

OK, I understand. What I don't understand is why the kernel thinks why
it needs page tables for more than 512M.

>> <sigh> So it sounds like that the kernel should balloon up the released
>> amount of memory. David, did we discuss this at some point and agreed that
>> was the proper way?
> I don't remember discussing it but it's an interesting idea.  Let me
> think about it.  It will need to work without the balloon driver (since
> it might not exist).

I'm not sure what you are discussing. Can you explain a little more?

I remember the good old times, kernel 2.6.18 and 2.6.38 with xen
patches, where free shows a total of 524620 kilobytes and xl list shows
512 megabytes, with dom0_mem=512M.
With 3.3, free shows a toal of 413920 and xl list shows 511 megabytes
for dom0.

Do you realize, that the numbers are very different? 524620 is very
close to 512 * 1024 while 413920 is very very different from 511 * 1024.


Xen-devel mailing list



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