From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: NUMA TODO-list for xen-devel Date: Wed, 1 Aug 2012 17:53:21 +0100 Message-ID: <50195F01.5020405@citrix.com> References: <1343837796.4958.32.camel@Solace> <501959BE.60801@citrix.com> <1343839634.4958.39.camel@Solace> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2161362334832821623==" Return-path: In-Reply-To: <1343839634.4958.39.camel@Solace> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli Cc: Andre Przywara , Anil Madhavapeddy , George Dunlap , xen-devel , Jan Beulich , "Zhang, Yang Z" List-Id: xen-devel@lists.xenproject.org --===============2161362334832821623== Content-Type: multipart/alternative; boundary="------------030103050606070408050209" --------------030103050606070408050209 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On 01/08/12 17:47, Dario Faggioli wrote: > On Wed, 2012-08-01 at 17:30 +0100, Andrew Cooper wrote: >> On 01/08/12 17:16, Dario Faggioli wrote: >> >> ... >> >>> - Automatic placement at guest creation time. Basics are there and >>> will be shipping with 4.2. However, a lot of other things are >>> missing and/or can be improved, for instance: >>> [D] * automated verification and testing of the placement; >>> * benchmarks and improvements of the placement heuristic; >>> [D] * choosing/building up some measure of node load (more accurate >>> than just counting vcpus) onto which to rely during placement; >>> * consider IONUMA during placement; >>> * automatic placement of Dom0, if possible (my current series is >>> only affecting DomU) >>> * having internal xen data structure honour the placement (e.g., >>> I've been told that right now vcpu stacks are always allocated >>> on node 0... Andrew?). >>> >> >> - Xen NUMA internals. Placing items such as the per-cpu stacks and >> data area on the local NUMA node, rather than unconditionally on node >> 0 at the moment. As part of this, there will be changes to >> alloc_{dom,xen}heap_page() to allow specification of which node(s) to >> allocate memory from. > > As you see, I already tried to consider that (as you told me it does > that couple of weeks ago :-) ). I'll add your wording of it (much better > than mine) to the wiki... I understand you're working on this, aren't > you? Can I put that down to? > > Thanks and Regards, > Dario > Wow - I completely managed to miss that while reading. Someone will be working on it for XS.next, and that someone will probably be me - put me down for it. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com --------------030103050606070408050209 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit
On 01/08/12 17:47, Dario Faggioli wrote:
> On Wed, 2012-08-01 at 17:30 +0100, Andrew Cooper wrote:
>> On 01/08/12 17:16, Dario Faggioli wrote:
>>
>> ...
>>
>>> - Automatic placement at guest creation time. Basics are there and
>>> will be shipping with 4.2. However, a lot of other things are
>>> missing and/or can be improved, for instance:
>>> [D] * automated verification and testing of the placement;
>>> * benchmarks and improvements of the placement heuristic;
>>> [D] * choosing/building up some measure of node load (more accurate
>>> than just counting vcpus) onto which to rely during placement;
>>> * consider IONUMA during placement;
>>> * automatic placement of Dom0, if possible (my current series is
>>> only affecting DomU)
>>> * having internal xen data structure honour the placement (e.g.,
>>> I've been told that right now vcpu stacks are always allocated
>>> on node 0... Andrew?).
>>>
>>
>> - Xen NUMA internals. Placing items such as the per-cpu stacks and
>> data area on the local NUMA node, rather than unconditionally on node
>> 0 at the moment. As part of this, there will be changes to
>> alloc_{dom,xen}heap_page() to allow specification of which node(s) to
>> allocate memory from.
>
> As you see, I already tried to consider that (as you told me it does
> that couple of weeks ago :-) ). I'll add your wording of it (much better
> than mine) to the wiki... I understand you're working on this, aren't
> you? Can I put that down to?
>
> Thanks and Regards,
> Dario
>

Wow - I completely managed to miss that while reading.  Someone will be working on it for XS.next, and that someone will probably be me - put me down for it.

--
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com

--------------030103050606070408050209-- --===============2161362334832821623== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2161362334832821623==--