[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86/numa: Adjust datatypes for node and pxm

>>> On 23.02.15 at 15:53, <boris.ostrovsky@xxxxxxxxxx> wrote:

> On 02/23/2015 09:47 AM, Jan Beulich wrote:
>>>>> On 23.02.15 at 15:42, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>> On 02/23/2015 04:57 AM, Jan Beulich wrote:
>>>>>>> On 21.02.15 at 19:14, <boris.ostrovsky@xxxxxxxxxx> 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.

Anything more complicated than a flat array would be nice, but
may pose a chicken-and-egg problem with allocating the memory
for it.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.