[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Fri, Sep 12, 2014 at 11:02:30AM +0200, Dario Faggioli wrote:
> [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! :-/
> 

Sorry from me as well. I've been tracking this discussion for some time
but never weighted in because I needed to get my other 8 patches ready
for the freeze. No pressure. ;-)

> > 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.
> 

Agreed. We just need to make the syntax backward compatible.

> 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.:
> 

I don't thin vnuma_maxmem reflects what this parameter means. The list
controls distribution of memory not the maximum amount. The sum of this
list should be equal to maxmem= in config file.

> 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).
> 

I think this syntax is good.

Wei.

> 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)
> 



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.