On Tue, 2007-09-04 at 11:18 +0900, Isaku Yamahata wrote:
> On Wed, Aug 29, 2007 at 10:33:06PM -0700, Alex Williamson wrote:
> > On Thu, 2007-08-30 at 13:17 +0800, Duan, Ronghui wrote:
> > > I make a new domain0 kernel with CONFIG_IA64_DIG .It still panic.
> > 
> > > (XEN) Maximum permitted dom0 size: 3973MB
> > 
> >    It looks like we need to reduce dom0 memory by the size of the
> > contiguous region the swiotlb makes.  By default, this is 64MB, so
> > booting with dom0_mem=3909M will probably work (at least that's the
> > difference on my 2G system).  Unfortunately the swiotlb can be resized
> > by a command line option, so statically removing 64MB isn't a very good
> > solution.  Perhaps we need a more efficient create_contiguous_region()?
> 
> - When the memory exchange hypercall fails,
>   kick balloon(or do something similar) and try the hypercall again.
>   Although the ballooning makes the posibility higher, it doesn't gurantee.
> 
> - Start dom0 with minimal memory (e.g. 128MB) assigned and other memory
>   is ballooned out when booting.
>   After dom0 allocating contiguous region, populate the unassigned memory.
> 
> Any other ideas?

Hi Isaku,

   I'm not sure I understand the mechanism by which memory would be
ballooned out in your second option.  Creating a non-fully populated
dom0, then expanding it seems a bit tricky.  It also leaves the question
of what's the right minimal memory amount (if NR_CPUS is set large, 128M
isn't enough to boot).  Your first option seems plausible, although this
needs to happen early enough that the balloon driver probably isn't
going to be much help.  Relinquishing dom0 memory certainly wouldn't
guarantee the create_contiguous_region() call would succeed, but it
would be nice to see how it behaves in practice.

> Given that dom0_mem is the easy work around, is it worth while
> to make effort?

   It's an easy work around if you're a developer and can recognize a
failure caused by too much/little dom0 memory.  For distribution support
we can't count on that.  We need defaults that provide a large enough
dom0 to be useful, and we need graceful failure mechanism should the
defaults not work.  Thanks,
        
        Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.


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

Reply via email to