Re: [Xen-devel] [PATCH RFC v2 0/7] xen: vNUMA introduction

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On ven, 2013-09-13 at 11:38 +0100, Jan Beulich wrote:
> >>> On 13.09.13 at 10:49, Elena Ufimtseva <ufimtseva@xxxxxxxxx> wrote:
> > VM config:
> > 
> > memory = 16384
> > vcpus = 8
> > name = "rcbig"
> > vnodes = 8
> > vnumamem = "2g, 2g, 2g, 2g, 2g, 2g, 2g, 2g"
> > vcpu_to_vnode ="5 6 7 4 3 2 1 0"
> 
> For an example it would probably be useful to use a more traditional
> case, i.e. more than one vCPU per vNode.
> 
Right... Perhaps Elena could post another example with such
characteristics, to show us what happens in that case? (And of course
use that for the cover letter of next version too :-P)

> Also, the settings above say nothing about the relationship to
> physical nodes, yet that's an important aspect for VM creation.
> Are you perhaps implying that each vNode would get assigned
> to a tool stack chosen pNode? 
>
Yep. So, right now, I don't think there is a way to specify an explicit
virtual to physical mapping, and what happens is exactly that: the
toolstack picks. However, I indeed agree that we want to introduce
something like that, to give the user full control, if he's interested
in it.

That being said, I also think that, if the user does not say anything
about that, having the toolstack choosing is a sane default.

> What if there are more vNodes
> than pNodes? 
>
That is the actual issue, from an UI perspective, on which I'd like some
discussion to happen... I'll send an e-mail with some more details on
that later.

> What if node distances vary, and the admin wants
> some control over the placement?
> 
Again, I totally agree: we should provide such mechanism.

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel