This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Andre Przywara <andre.przywara@xxxxxxx>
Subject: Re: [xen-devel][vNUMA v2][PATCH 2/8] public interface
From: Dulloor <dulloor@xxxxxxxxx>
Date: Tue, 3 Aug 2010 08:24:16 -0700
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 03 Aug 2010 08:25:11 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=m5OO/CXy47maVwUP28hDr+OYuVSOc1BZHzGYnXKKrUI=; b=xT4bMw/b56HPuWSrFtt2kjl3IuvxSdBZ54KrRxjPBglAqQSuE5kfWBloAR8wClNA3P 8bIIDEV+oQanWE8sJkLORmXDGoBV66ncSObDru/uQCCz1zPdZpF9C5Kd9b/BYdJzQCtt XLhvwu75z5YzqvMYLLcqEJqM40MXlfG90+rok=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wegLmolnbsSadZ9Q6tFNnGn42zQOsMvOQ0kMDVSASZFBsujX4uU5sgH8pumLdrDvAj DPKtPJBiU3cyikAFHis3fQaIScAgxDPn8mEXTMSiitfFSNVxqRIID6mhvEV1/wbBaLWl Xzzl6ZBadmCNIyGNfZ/S4ayr3Skd+mA6HQVN8=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C580E36.9040808@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1BEA8649F0C00540AB2811D7922ECB6C9338B4CC@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <AANLkTimK3KCFz8K7ETcJtOVe9kSCXnhN0BKnrFKkvwMd@xxxxxxxxxxxxxx> <AANLkTimSDabceF5sFwHK3N6a0X1eYiFqaF6BgGhbVcj6@xxxxxxxxxxxxxx> <4C580E36.9040808@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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