On Mon, Apr 30, 2007 at 02:59:08PM -0400, Charles Coffing wrote:
> On Fri, Apr 27, 2007 at 7:26 AM, "Daniel P. Berrange" <berrange@xxxxxxxxxx>
> wrote:
> > On Fri, Apr 27, 2007 at 07:53:24AM +0100, Keir Fraser wrote:
> >> On 27/4/07 00:12, "Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote:
> >>
> >> > The _constructDomain call is failing in xc.domain_create() - the code
> >> > which
> >> > deals with ballooning down Domain-0 is not even run yet - that lives in
> >> > the _initDomain method. So HVM domain creation is failing before XenD has
> >> > even had a chance to do ballooning. If I manually use 'xm mem-set' to
> >> > balloon down Domain-0 ahead of time, everything works just fine.
> >> >
> >> > I'm at a lose to figure out how to solve this without major re-arranging
> >> > of the order of _constructDomain & _initDomain work. Perhaps someone can
> >> > figure out an easier fix ?
> >>
> >> I don't think domain_create() allocates very many pages, although it's
> >> possible it's making a default allocation of shadow memory. Assuming not,
> >> it
> >> may be sufficient to make auto-balloon leave a bit of slack memory rather
> >> than try to account for all available memory down to the last page. A few
> >> pages might turn out to suffice. Does this problem occur with the very
> >> first
> >> domain you try to create after booting the machine?
> >
> > It seems to occurr with any HVM guest I try to create, unless there was
> > already
> > some free mem (from starting & stopping a previous dom). I'm testing with
> > this
> > very simple hack which seems to make it work - just ensure the balloon
> > driver
> > frees a 10 MB chunk right at the start. Hardcoding is fine because when we
> > later get to the _initDomain() method we'll definitely be freeing up much
> > more than 10 MB for the HVM guests's actual mem requirements.
>
>
> Keir,
>
> The problem Daniel fixed for fully virtual affects paravirtual, also.
>
> We have received bug reports from ISVs of this problem in both the PV
> and FV cases. I traced code paths and discovered that FV attempts to
> allocate the most memory during the initial domain creation; 64-bit PV
> allocates the next most; 32-bit PV allocates the least. So failures
> for PV are less common, but not impossible.
Indeed - in testing on 64-bit PV over the weekend I saw perhaps 1 in 5
PV creation attempts fail with the not enough memory bug. So it does look
like the patch needs to be de-indented to fix PV too.
Regards,
Dan
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home