All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Liu <wei.liu2@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Matt Wilson <msw@linux.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>, Wei Liu <Wei.Liu2@citrix.com>,
	Elena Ufimtseva <ufimtseva@gmail.com>
Subject: Re: [PATCH v10 9/9] libxl: vnuma topology configuration parser and doc
Date: Fri, 12 Sep 2014 10:31:00 +0100	[thread overview]
Message-ID: <20140912093100.GD31343@zion.uk.xensource.com> (raw)
In-Reply-To: <1410512550.4005.243.camel@Solace.lan>

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

  reply	other threads:[~2014-09-12  9:31 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-03  4:24 [PATCH v10 3/9] vnuma hook to debug-keys u Elena Ufimtseva
2014-09-03  4:24 ` [PATCH v10 4/9] libxc: Introduce xc_domain_setvnuma to set vNUMA Elena Ufimtseva
2014-09-03 14:53   ` Ian Campbell
2014-09-03  4:24 ` [PATCH v10 5/9] libxl: vnuma types declararion Elena Ufimtseva
2014-09-03 15:03   ` Ian Campbell
2014-09-03 16:04   ` Ian Campbell
2014-09-04  3:48     ` Elena Ufimtseva
     [not found]       ` <1409826927.15057.22.camel@kazak.uk.xensource.com>
2014-09-08 16:13         ` Dario Faggioli
2014-09-08 19:47           ` Elena Ufimtseva
2014-09-16  6:17         ` Elena Ufimtseva
2014-09-16  7:16           ` Dario Faggioli
2014-09-16 12:57             ` Elena Ufimtseva
2014-09-03  4:24 ` [PATCH v10 6/9] libxl: build numa nodes memory blocks Elena Ufimtseva
2014-09-03 15:21   ` Ian Campbell
2014-09-04  4:47     ` Elena Ufimtseva
2014-09-05  3:50     ` Elena Ufimtseva
2014-09-12 10:18   ` Dario Faggioli
2014-09-03  4:24 ` [PATCH v10 7/9] libxc: allocate domain memory for vnuma enabled Elena Ufimtseva
2014-09-03 15:26   ` Ian Campbell
2014-09-12 11:06   ` Dario Faggioli
2014-09-03  4:24 ` [PATCH v10 8/9] libxl: vnuma nodes placement bits Elena Ufimtseva
2014-09-03 15:50   ` Konrad Rzeszutek Wilk
2014-09-03 15:52   ` Ian Campbell
2014-09-12 16:51   ` Dario Faggioli
2014-09-03  4:24 ` [PATCH v10 9/9] libxl: vnuma topology configuration parser and doc Elena Ufimtseva
2014-09-03 15:42   ` Konrad Rzeszutek Wilk
2014-09-11 17:13   ` Dario Faggioli
2014-09-12  2:04     ` Elena Ufimtseva
2014-09-12  9:02       ` Dario Faggioli
2014-09-12  9:31         ` Wei Liu [this message]
2014-09-12  9:59           ` Dario Faggioli
2014-09-03 15:37 ` [PATCH v10 3/9] vnuma hook to debug-keys u Konrad Rzeszutek Wilk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140912093100.GD31343@zion.uk.xensource.com \
    --to=wei.liu2@citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=dario.faggioli@citrix.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=keir@xen.org \
    --cc=msw@linux.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=ufimtseva@gmail.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.