On Sat, Jun 16, 2007 at 10:57:43AM +0200, Tristan Gingold wrote:
> On Sat, Jun 16, 2007 at 02:23:21PM +0800, Zhang, Xing Z wrote:
> > >>
> > >> Unfortunately it breaks VTi domains somehow. My system hangs when
> > I
> > >> try to xm create one. Thanks,
> > >
> > >Thats bizarre given it's a simple heap increase. However I cannot help
> > >debug this right now as I don't have a box with VT to play with right
> > >now.
> > >
> > [Zhang, Xing Z]
> > Hi Sorensen, I have some comments on this patch. I noticed you increase
> > xen heap to 256M. But current xen heap is 64M TR mapped ( use
> > KERNEL_TR_PAGE_SHIFT macro in xen/arch/linux-xen/head.S). So Xen has
> > 256M heap but 64M TR mapping area with your patch, this should be reason
> > why VTI hang. Not only VTI, I think XenU has same issue because struct
> > vcpu located in xen heap and it must be TR mapped.
> > Maybe boot more XenU guests will show the issue.
> This is certainly the reason of the crash!
So it's the reason why xenheap_megabytes boot option is disabled
intentionally.
Given that xen/ia64 supports virtual frame table and altix has
very sparsely allocated RAM layout, I'm suspencting that allocation
bitmap in page allocater of common code is the culprit.
It is single big bitmap.
So I suppose that the bitmap should made NUMA node aware, then
the pressure on xenheap will be greatly decreased.
Off course, there remains scalability limits caused by xenheap size.
But at first we should estimate memory usage on xenheap and necessary
scalability to determine what is a dominant issue.
--
yamahata
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home