From: "Sven Köhler" <sven.koehler@gmail.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: dom0 not seeing all of the assigned memory
Date: Mon, 19 Mar 2012 13:25:45 +0100 [thread overview]
Message-ID: <4F6725C9.9000304@gmail.com> (raw)
In-Reply-To: <4F6713EC.7070804@citrix.com>
[-- Attachment #1.1: Type: text/plain, Size: 3541 bytes --]
Am 19.03.2012 12:09, schrieb David Vrabel:
> On 15/03/12 20:07, Sven Köhler wrote:
>> 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?
>
> Because the pages are not accessible. They overlap with BIOS or device
> memory.
>
> Later kernels are better at releasing more pages than earlier ones and
> so it may appear that the domain ends up with less pages but it really
> has the same number of usable pages.
This all makes sense. But I don't have the feeling, this is a proper
explanation of what I'm seeing.
"xl list" shows that dom0 is still at 511M. If the pages were really
released back to the hypervisor, then "xl list" should show an amount of
memory somewhere near the the value that "free" shows. But this isn't
the case. Was it wrong when I said that the pages are passed back to the
hypervisor?
>>>>>> 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.
>
> The documentation isn't great. dom0_mem sets two memory related limits:
> a) the initial number of pages; and b) the maximum possible number of
> pages (maximum reservation).
As far as I can see, there are three variables here:
- the initial amount of pages that dom0 gets
- the minimal amount of pages that dom0 should have
- the maximal amount of pages that dom0 can have
Please please fix the documentation!
Rumors about what dom0_mem=X does are spreading. And most pages I found
said that it would statically assign memory to dom0. What you're saying
sounds like dom0 is still allowed to grow if one does only use
dom0_mem=X but not dom0_mem=max:X - which is more dynamic than static.
> Without the 'max:' option, the maximum reservation is unlimited.
>
> Since 3.0.5, Linux has used the minimum of the maximum reservation and
> the total amount of physical RAM to size its page tables etc.
I tried dom0_mem=max:512M as far as I remember. And it didn't improve
the situation (kernel 3.2.10). Also, when dom0 is booting without xen,
the amount of memory shown by free was not nearly as far away from the
amount of physical ram as when dom0 is booting with xen and dom0_mem=...
Something still smells fishy to me!
Anyway: I hope some of the developers have reproduced the problem and
are about to fix it.
Regards,
Sven
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2012-03-19 12:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-22 22:19 dom0 not seeing all of the assigned memory Henrik Olsson
2012-02-22 22:40 ` Henrik Olsson
2012-02-23 18:55 ` David Vrabel
2012-02-27 17:34 ` Henrik Olsson
2012-02-27 19:04 ` Roderick Colenbrander
2012-03-11 22:20 ` Sven Köhler
2012-03-15 18:33 ` Konrad Rzeszutek Wilk
2012-03-15 18:54 ` David Vrabel
2012-03-15 20:07 ` Sven Köhler
2012-03-15 20:13 ` Ian Campbell
2012-03-15 20:29 ` Sven Köhler
2012-03-15 21:55 ` Ian Campbell
2012-03-15 22:09 ` Sven Köhler
2012-03-19 11:09 ` David Vrabel
2012-03-19 12:25 ` Sven Köhler [this message]
2012-03-19 12:30 ` Fantu
2012-04-17 4:33 ` Brian Szymanski
2012-04-17 4:46 ` Brian Szymanski
2012-04-17 21:30 ` Dan Magenheimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F6725C9.9000304@gmail.com \
--to=sven.koehler@gmail.com \
--cc=david.vrabel@citrix.com \
--cc=konrad.wilk@oracle.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).