WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

Re: [Xen-ia64-devel] sparsemem/discontig?

To: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Subject: Re: [Xen-ia64-devel] sparsemem/discontig?
From: Jes Sorensen <jes@xxxxxxx>
Date: 15 Sep 2006 06:06:09 -0400
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 15 Sep 2006 03:06:24 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <B1AC58F6B4AE1B43972576AD3125882E17CECB@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <B1AC58F6B4AE1B43972576AD3125882E17CECB@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
>>>>> "Dan" == Magenheimer, Dan (HP Labs Fort Collins) <dan.magenheimer@xxxxxx> 
>>>>> writes:

Dan> Some ancient history which might be of interest can be found at:
Dan> http://lists.xensource.com/archives/html/xen-devel/2005-03/msg00815.html

Dan,

Mmmmmmm, be honest about it, you really just tried to discourage me
and scare me away, right?

On the long term Xen will need NUMA awareness in it's allocator, not
just on ia64, but also on x86_64 to achieve any level of useful
performance. Pretending we can just do it in simple little pools are
unlikely to work.

But I agree, on the longer term, discontig support is the main issue
and without a virtual mem map .... oh well :( When was the last time
someone saw an ia64 box with just one chunk of memory?

Right now I am getting this output from Xen on a small Altix (4 nodes,
8 cpus, 6GB of RAM):

(XEN) Init boot pages: 0x3003000120 -> 0x3014000000.
(XEN) Init boot pages: 0x3018000000 -> 0x307bffc000.
(XEN) Init boot pages: 0xb003000000 -> 0xb07c000000.
(XEN) Init boot pages: 0x13003000000 -> 0x1303c000000.
(XEN) Init boot pages: 0x1b003000000 -> 0x1b038ec5000.
(XEN) Init boot pages: 0x1b039da8d20 -> 0x1b03a3a4010.
(XEN) Init boot pages: 0x1b03a3a4070 -> 0x1b03a3a7fcd.
(XEN) Init boot pages: 0x1b03a3a8010 -> 0x1b03a42c010.
(XEN) Init boot pages: 0x1b03a42cbe0 -> 0x1b03a7fc000.
(XEN) Init boot pages: 0x1b03b800000 -> 0x1b03bd64000.
(XEN) Init boot pages: 0x1b03bda0000 -> 0x1b03be10000.
(XEN) Init boot pages: 0x1b03be80000 -> 0x1b03bea0000.

I haven't checked yet whether the code receiving those tables does
anything with it to round up to granule alignment etc. otherwise it
could explain why the thing explodes for me.

But what it does is that it takes forever to get to the point where it
prints the total System RAM - in fact at first I thought the system
had crashed and only because I once left it for several minutes did I
end up seeing this output :(

Jes

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