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-devel

[Xen-devel] RE: [PATCH] x86: fix NUMA handling (c/s 20599)

>>> "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> 07.01.10 04:03 >>>
>But for this specific SRAT, seems we can also improve constructing of
>node_memblk_range[], so that we can merge 0~a0000 with
>100000-80000000, and  80000000-d0000000 with
>100000000-130000000. Depends on whether we need keep BIOS's
>memory affinity information, we can either create a new structure to
>hold the result, or we can simply compact node_memblk_range[]. The
>benefit is, we can reduce the sizeof memnodemap, but I'm not sure
>if it is needed still after this patch.

Yes, I had considered this too. But since this is code ported from Linux,
I'd like to get buy-off on this on the Linux side first. (And yes, I do
think this would be an improvement - not just because of the memory
savings, but also because of the [perhaps significantly] reduced
cache footprint resulting from the array accesses: Only two array
elements are really needed for the shown memory layout.)

Why would you, btw., think that BIOS affinity information would get
lost when merging entries in this case?

Jan


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

<Prev in Thread] Current Thread [Next in Thread>