This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH Xen-unstable] Balloon down memory to achive enoug

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH Xen-unstable] Balloon down memory to achive enough DMA32 memory for PV guests with PCI pass-through to succesfully launch.
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Mon, 16 Nov 2009 10:04:39 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, keir.fraser@xxxxxxxxxxxxx
Delivery-date: Mon, 16 Nov 2009 07:06:08 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B01314F020000780001FDE4@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20091113221602.GA30243@xxxxxxxxxxxxxxxxxxx> <4B01314F020000780001FDE4@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.19 (2009-01-05)
On Mon, Nov 16, 2009 at 10:02:39AM +0000, Jan Beulich wrote:
> >>> Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 13.11.09 23:16 >>>
> >Balloon down memory to achive enough DMA32 memory for PV guests with PCI 
> >pass-through to succesfully launch.
> >
> >If the user hasn't used dom0_mem= bootup parameter, the privileged domain
> >usurps all of the memory. During launch of PV guests with PCI pass-through
> >we ratchet down the memory for the privileged domain to the required memory
> >for the PV guest. However, for PV guests with PCI pass-through we do not
> >take into account that the PV guest is going to swap its SWIOTLB memory
> >for DMA32 memory - in fact, swap 64MB of it. This patch balloon's down
> >the privileged domain so that there are 64MB of DMA32 memory available.
> While I realize that the patch was already committed, I still wanted to
> raise my concerns with it:

Thank you for raising them.
> For one, it is logically (just for a much smaller total amount and for a more
> narrow memory range) identical to what would be needed for 32-bit-pv
> DomU-s on 64-bit hv, so *if* this patch is considered conceptually valid,

Meaning if you want to run a 8GB 32-bit PV, do the same. But if the PV is
say, using 512MB, there is no need to allocate 64MB?

> then it should be abstracted and used for both purposes.
> I think, however, that it is conceptually wrong, because it may mean that
> all of the memory possibly removable from Dom0 can get ballooned out
> without in fact yielding the memory needed by the to be started DomU.

There is a limit at which it stops. Perhaps I should add a failsafe
wherein if we don't get enough of the memory, we give it back to Dom0?

> Besides that, hard-coding the value to 64Mb doesn't seem very nice
> either (while I realize that both 2.6.18 and pv-ops default to 64Mb, I
> do not think this is really appropriate, especially given that in the 2.6.18
> tree Dom0 can get run with as little as 2Mb, and I highly doubt that the
> demand of a DomU can by default be assumed to exceed that of Dom0),
> and in particular doesn't help with the case where one really has to use
> a larger than the default size swiotlb.

Sure. But the user will get a notice in the log pointing them to the fact that
we could not get enough memory. Maybe I should expand it some more and say
something along these lines: "You best bet is to use dom0_mem=2GB. We've tried
to deflate the amount of memory the privileged domain is using, but we fear
to go any lower. Your guest might not start."

Since the SWIOTLB size is determined by the 'swiotlb' argument passed to
the guest, what if we scanned for that and if it has a number, calculate
how much memory that amounts to and use that value? The default still being at 

Xen-devel mailing list