Re: [xen-devel][vNUMA v2][PATCH 2/8] public interface

[Dulloor <dulloor@xxxxxxxxx>]

On Tue, Aug 3, 2010 at 5:40 AM, Andre Przywara <andre.przywara@xxxxxxx> wrote:
> Dulloor wrote:
>>
>> Interface definition. Structure that will be shared with hvmloader (with
>> HVMs)
>> and directly with the VMs (with PV).
>>
>> -dulloor
>>
>> Signed-off-by : Dulloor <dulloor@xxxxxxxxx>
>>
>> +struct xen_vnode_info {
>> +    uint8_t mnode_id;  /* physical node vnode is allocated from */
>> +    uint32_t start;    /* start of the vnode range (in pages) */
>> +    uint32_t end;             /* end of the vnode range (in pages) */
>> +};
>
> Is there a particular reason you made the start and end members 32bit only?
> This effectively limits the amount of memory to 16TB, which is not that
> far from being used (if not larger NUMA machines already shipping with
> this amount of memory).
> So can you push these variables to 64 bits?
Yeah. Keir had asked for this too. I guess I missed it. Will do that.

>>
>> +struct xen_domain_numa_info {
>> +    uint8_t version;    /* Interface version */
>> +    uint8_t type;       /* VM memory allocation scheme (see above) */
>> +
>> +    uint8_t nr_vcpus;
>> +    uint8_t nr_vnodes;
>
> The same for here. I'd like to see at least nr_vcpus to be prepared for more
> than 256 vCPUs.
> Please keep in mind that if Dom0 is also NUMA aware, by default the whole
> host resources are first given to Dom0, so the NUMA info should not be
> restricted to the size of a typical guest only.
Sure. I will change nr_vcpus and nr_vnodes to 16-bits each ?
And, thats a good point about Dom0. I have a patch ready in queue
which allows for Dom0
to be made NUMA-aware. I would expect control and driver code in Dom0
to benefit from that.


>
> Regards,
> Andre.
>
> --
> Andre Przywara
> AMD-Operating System Research Center (OSRC), Dresden, Germany
> Tel: +49 351 448-3567-12
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel