Re: [Xen-devel] [PATCH v10 9/9] libxl: vnuma topology configuration parser and doc

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

[Adding Wei]

On gio, 2014-09-11 at 22:04 -0400, Elena Ufimtseva wrote:
> Hello Dario
> 
Hi,

> Thank you for such a thorough review.
>
Yeah, well, sorry it took a bit! :-/

> Majority of comments make sense to me.
>
Cool. :-D

> Now I wanted to ask about the memory ranges :)
> I am not sure at this point I should have them parsed in config file
> (for the case where vNUMA node has multiple ranges) and as Ian has
> mentioned I will be moving
> these ranges away from libxl build info.
> I guess for now It will be better to leave these ranges out of scope
> of parsing code.
> What do you think?
> 
If, as I'm quite sure, with 'memory ranges' you're now talking about the
possibility of specifying more memory region for each node, yes, given
that we're keeping that out of the libxl interface, I'd live them out of
xl too.

If, with 'memory ranges', you mean the possibility of specifying
different memory size for each node, I think I'd keep this.

In fact, bbout memory, I'm fine with how you right now deal with
vnuma_mem (which I suggested to rename to "vnuma_memory" or
"vnuma_maxmem"), i.e.:

vnuma_memory = [1024, 1024, 2048, 2048]

When, in future, we will introduce toolstack support for defining nodes
with multiple memory regions, we can extend this syntax quite easily, to
something like

vnuma_memory = ["128,896", 256,256,512"]

with the following meaning: we have two nodes; node 0 has two regions,
one 128MB big, the other 896MB big. Node 1 has 3 regions, the first twos
256MB big, the third 512MB big.

Just to give an example.

If we want, that can be even more specific, i.e.:

vnuma_memory = ["128@0xffffaaa,896@0xccccdddd", ...]

meaning: node 0 has one region 128MB big, starting at address 0xffffaaa,
and another 896MB big, starting at address 0xccccdddd (ISTR we agreed on
something very similar to this for Arianna's iomem series).

This is just an example, of course, the point being that the current
interface is good for now, and can be easily extended, in a backward
compatible way.

This is my take on this, hoping I understood your question. Ian's
opinion is probably the one you want, though. :-)

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