RE: [Xen-devel] xen: memory initialization/balloon fixes (#3)

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> From: David Vrabel [mailto:david.vrabel@xxxxxxxxxx]
> Sent: Thursday, September 22, 2011 6:32 AM
> To: Dan Magenheimer
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Konrad Wilk
> Subject: Re: [Xen-devel] xen: memory initialization/balloon fixes (#3)
> 
> On 20/09/11 17:57, Dan Magenheimer wrote:
> >
> > Thanks for your patches!  I am looking at a memory capacity/ballooning
> > weirdness that I hoped your patchset might fix, but so far it has not.
> > I'm wondering if there was an earlier fix that you are building upon
> > and that I am missing.
> >
> > My problem occurs in a PV domU with an upstream-variant kernel based
> > on 3.0.5.  The problem is that the total amount of memory as seen
> > from inside the guest is always substantially less than the amount
> > of memory seen from outside the guest.  The difference seems to
> > be fixed within a given boot, but assigning a different vm.cfg mem=
> > changes the amount.  (For example, the difference D is about 18MB on
> > a mem=128 boot and about 36MB on a mem=1024 boot.)
> 
> I don't see the problem?

Hi David --

Sorry, just to clarify, are you saying you are seeing the same
behavior and don't consider it a problem, or that you are not
seeing the same difference?

> The MemTotal value /proc/meminfo doesn't include some pages reserved by
> the kernel which is why it's less than the maximum reservation of the
> domain.

I'm aware of that... "some" has been a fixed size of a few megabytes
in Xen for a long time.  I am seeing 30-60MB or more.

If you are never seeing a difference more than a few MB, maybe
I've misapplied your patches (as they didn't apply cleanly and
I had to do some manual patching).
 
> > Part B of the problem (and the one most important to me) is that
> > setting /sys/devices/system/xen_memory/xen_memory0/target_kb
> > to X results in a MemTotal inside the domU (as observed by
> > "head -1 /proc/meminfo") of X-D.  This can be particularly painful
> > when X is aggressively small as X-D may result in OOMs.
> > To use kernel function/variable names (and I observed this with
> > some debugging code), when balloon_set_new_target(X) is called
> > totalram_pages gets driven to X-D.
> 
> Again, this looks like the correct behavior to me.

Hmmm... so if a user (or automated tool) uses the Xen-defined
API (i.e. /sys/devices/system/xen_memory/xen_memory0/target_kb)
to use the Xen balloon driver to attempt to reduce memory usage
to 100MB, and the Xen balloon driver instead reduces it to
some random number somewhere between 40MB and 90MB, which
may or may not cause OOMs, you consider this correct behavior?

(Cc'ing a couple of ballooning old-timers to ensure I am not
misunderstanding the intended API.)

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel