On Wed, 2011-02-23 at 15:26 +0800, Thomas Goirand wrote:
> On 02/03/2011 06:29 PM, Bastian Blank wrote:
> > On Thu, Feb 03, 2011 at 05:28:30PM +0800, Thomas Goirand wrote:
> >> On 02/03/2011 04:34 PM, Bastian Blank wrote:
> >>> Please provide all informations. xm dmesg, the kernel log, xm info.
> >> How, if the server reboots when I do it?
> >
> > Well, then remove the call and gather the information before breaking
> > the system. For anything else, use a serial console.
>
> With the same server, when I put:
> GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=512M"
> in my /etc/default/grub, the dom0 is fine, running on 501 MB of RAM. If
> I don't put this option, then shrink from something like 8 GB (the
> server has 12 GB total) to bellow 800, it crashes, with no memory to
> release. That's strange, because with 512 MB to the dom0, only 180M is
> used, while when I give above 1GB, there's about 800MB of "used RAM",
> and it can't be freed.
>
> Any idea why it's ok to boot with 512MB on the dom0, but not ok to
> mem-set Domain-0 to it? To me, it seems more a Linux issue than a Xen one...
Linux (indeed most OSes) size certain data structures at start of day
based on the amount of RAM (potentially) present. The size of these data
structures does not change when ballooning occurs and since they must
live in kernel memory they create a lower bound on how small you can
balloon a given guest. The main one I am thinking of is the frame table
(which contains an entry for every memory page in the system).
On the face of it going from 8G -> 512M doesn't seem to be all that
unreasonable though and I don't think the frame table would account for
the full 800M overhead you are seeing.
Please post a kernel and hypervisor dmesg from a boot with the larger
amount of dom0 mem. The content of /proc/meminfo might be useful too as
would /proc/{buddy,slab}info if your system has them.
Ian.
--
Ian Campbell
Memory fault -- brain fried
signature.asc
Description: This is a digitally signed message part
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|