Re: [Xen-devel] [PATCH RFC v2 1/7] xen/vNUMA: vNUMA support for PV guests.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.09.13 at 08:44, Elena Ufimtseva <ufimtseva@xxxxxxxxx> wrote:

Please don't top post.

> George, after talking to Dario, I think the max number of physical
> nodes will not exceed 256. Dario's automatic NUMA
> placement work with this number and I think it can be easily u8.
> Unless anyone has other thoughts.

With nr_vnodes being uint16_t, the vnode numbers should be
too. Limiting them to u8 would possibly be even better, but then
nr_vnodes would better be unsigned int (perhaps that was the
case from the beginning, regardless of the types used for the
arrays).

The pnode array surely can also be uint8_t for the time being,
considering that there are other places where node IDs are
limited to 8 bits.

And with struct acpi_table_slit having just 8-bit distances, there's
no apparent reason why the virtual distances can't be 8 bits too.

But - all this is only for the internal representations. Anything in
the public interface should be wide enough to allow future
extension.

Jan

>>> @@ -89,4 +90,14 @@ extern unsigned int xen_processor_pmbits;
>>>
>>>  extern bool_t opt_dom0_vcpus_pin;
>>>
>>> +struct domain_vnuma_info {
>>> +    uint16_t nr_vnodes;
>>> +    uint *vdistance;
>>> +    uint *vcpu_to_vnode;
>>> +    uint *vnode_to_pnode;
>>> +    vnuma_memblk_t *vnuma_memblks;
>>> +};
>>
>> Are these the right sizes for things to allocate?  Do we really need
>> 32 bits to represent distance, vnode and pnode?  Can we use u16 or u8?



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel