On Tue, Sep 04, 2007 at 02:06:18PM -0600, Alex Williamson wrote:
> 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.
How about this option?
- Allocate pseudo physical contiguous region from the end of
conventional memory and relinquish at somewhere of the booting
process. It would be almost the same effect ot reduce dom0 size by xen.
Probably at the time dom0 switching from the init bootmem allocator to
the buddy allocator or before the swith.
With the buddy allocator it would be somewhat difficult.
I missed the trivial option.
- Xen parses dom0 command line looking for "swiotlb=", and
reduce dom0 size more. Too easy/hacky?
> 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,
Sounds reasonable.
Even if we suggest to reduce dom0_mem with the panic message,
they won't read the message saying only panic or discarding Xen
with silence.
--
yamahata
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home