There was the beginning of a discussion regarding Xen on NUMA
machines recently on the following thread:
http://article.gmane.org/gmane.comp.emulators.xen.devel/10859
I think it would be great to have some better "large" (e.g.
NUMA, discontig, etc) memory support on Xen. However, this
is almost entirely in core Xen code now so it would have
to be coordinated with the core team and at least not break x86.
You may recall that I was trying to preserve the capability
to support NUMA and discontig machines, but was overruled.
See:
http://article.gmane.org/gmane.comp.emulators.xen.devel/7795
In any case, for what it's worth, you certainly have "my
blessing". Feel free to start a new thread on xen-devel
suggesting cooperation.
Dan
> -----Original Message-----
> From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf
> Of Greg Edwards
> Sent: Wednesday, June 15, 2005 3:04 PM
> To: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-ia64-devel] virtual mem map?
>
> Dan,
>
> Currently, arch/ia64/efi.c has the following hunk added to it:
>
> 330 // this is a temporary hack to avoid CONFIG_VIRTUAL_MEM_MAP
> 331 if (md->phys_addr >= 0x100000000) continue;
>
> This is problematic right off the bat for SGI systems, since we have
> huge holes in the efi memory map. For instance, on a small
> 2p/2GB box,
> it looks like:
>
> mem00: type=13, attr=0x8000000000000009,
> range=[0x0000000001000000-0x0000000002000000) (16MB)
> mem01: type=8, attr=0x9,
> range=[0x0000003000000000-0x0000003000010000) (0MB)
> mem02: type=6, attr=0x8000000000001001,
> range=[0x0000003000010000-0x0000003000080000) (0MB)
> mem03: type=4, attr=0x1,
> range=[0x0000003000080000-0x0000003000400000) (3MB)
> mem04: type=6, attr=0x8000000000001009,
> range=[0x0000003000400000-0x0000003002000000) (28MB)
> mem05: type=6, attr=0x8000000000000009,
> range=[0x0000003002000000-0x0000003003000000) (16MB)
> mem06: type=4, attr=0x9,
> range=[0x0000003003000000-0x0000003006000000) (48MB)
> mem07: type=7, attr=0x9,
> range=[0x0000003006000000-0x0000003014000000) (224MB)
> mem08: type=2, attr=0x9,
> range=[0x0000003014000000-0x0000003014cb5000) (12MB)
> mem09: type=7, attr=0x9,
> range=[0x0000003014cb5000-0x0000003079326000) (1606MB)
> mem10: type=2, attr=0x9,
> range=[0x0000003079326000-0x000000307a326000) (16MB)
> mem11: type=7, attr=0x9,
> range=[0x000000307a326000-0x000000307a3de000) (0MB)
> mem12: type=2, attr=0x9,
> range=[0x000000307a3de000-0x000000307a3f8000) (0MB)
> mem13: type=1, attr=0x9,
> range=[0x000000307a3f8000-0x000000307a452000) (0MB)
> mem14: type=4, attr=0x9,
> range=[0x000000307a452000-0x000000307a7fe000) (3MB)
> mem15: type=6, attr=0x8000000000000009,
> range=[0x000000307a7fe000-0x000000307b800000) (16MB)
> mem16: type=4, attr=0x9,
> range=[0x000000307b800000-0x000000307b801000) (0MB)
> mem17: type=7, attr=0x9,
> range=[0x000000307b801000-0x000000307b86e000) (0MB)
> mem18: type=4, attr=0x9,
> range=[0x000000307b86e000-0x000000307b894000) (0MB)
> mem19: type=7, attr=0x9,
> range=[0x000000307b894000-0x000000307b895000) (0MB)
> mem20: type=4, attr=0x9,
> range=[0x000000307b895000-0x000000307b9fe000) (1MB)
> mem21: type=7, attr=0x9,
> range=[0x000000307b9fe000-0x000000307bd72000) (3MB)
> mem22: type=5, attr=0x8000000000000009,
> range=[0x000000307bd72000-0x000000307bdac000) (0MB)
> mem23: type=3, attr=0x9,
> range=[0x000000307bdac000-0x000000307bdfe000) (0MB)
> mem24: type=7, attr=0x9,
> range=[0x000000307bdfe000-0x000000307be10000) (0MB)
> mem25: type=5, attr=0x8000000000000009,
> range=[0x000000307be10000-0x000000307be7e000) (0MB)
> mem26: type=7, attr=0x9,
> range=[0x000000307be7e000-0x000000307bea2000) (0MB)
> mem27: type=6, attr=0x8000000000000009,
> range=[0x000000307bea2000-0x000000307c000000) (1MB)
> mem28: type=12, attr=0x8000000000000001,
> range=[0x1ffffffffc000000-0x2000000000000000) (64MB)
>
> Xen doesn't find a place to stash the dom0 kernel.
>
> Do I have your blessing to look at adding CONFIG_VIRTUAL_MEM_MAP and
> CONFIG_DISCONTIGMEM support, or are there other suggestions out there
> about how to handle it?
>
> Greg
>
> _______________________________________________
> Xen-ia64-devel mailing list
> Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-ia64-devel
>
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home