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

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

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

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


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



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