On 02/23/2015 09:47 AM, Jan Beulich wrote:
On 23.02.15 at 15:42, <boris.ostrov...@oracle.com> wrote:
On 02/23/2015 04:57 AM, Jan Beulich wrote:
On 21.02.15 at 19:14, <boris.ostrov...@oracle.com> wrote:
--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -21,44 +21,55 @@
#include <asm/e820.h>
#include <asm/page.h>
+#define MAX_PXM 255
Perhaps better (MAX_NUMNODES - 1) than a literal number? Or
even do away with it altogether, use MAX_NUMNODES - 1 in the
array definition and ARRAY_SIZE() elsewhere?
I am not sure we can do this: PXMs are not guaranteed to be zero-based.
And, in fact, the way we map PXMs to nodes is not quite right because of
this --- it just so happens that PXMs are usually under 255 (and
zero-based) and we can use them as index to 255-sized array. IIRC the
spec defines them as 32-bit values.
Ah, yes, you're right. We may need to allocate the array dynamically
as soon as we run into a system with large PXMs.
But then we may end up with a huge and very sparse array. Maybe a hash
with each element as a linked list? We will hit the first element in
pretty much all cases so it should be reasonably fast.
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
