[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 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |