All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Dario Faggioli <dario.faggioli@citrix.com>, ufimtseva@gmail.com
Cc: Wei Liu <wei.liu2@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: vnuma toolstack extension request
Date: Wed, 24 Sep 2014 12:59:36 -0400	[thread overview]
Message-ID: <20140924165936.GB7354@laptop.dumpdata.com> (raw)
In-Reply-To: <1411574964.4336.35.camel@Solace.lan>

On Wed, Sep 24, 2014 at 06:09:24PM +0200, Dario Faggioli wrote:
> On mer, 2014-09-24 at 11:24 -0400, Elena Ufimtseva wrote:
> 
> > 
> > On Wed, Sep 24, 2014 at 11:15 AM, Konrad Rzeszutek Wilk
> > <konrad.wilk@oracle.com> wrote:
> 
> >         Hey Elena,
> > 
> > 
> > Hi Konrad
> >
> Hi Elena and Konrad,
>  
> >         Before you invest time in this, a couple of questions:
> >         
> >          - Dariof was interested in merging this with his auto NUMA
> >         placement code.
> >            That piece of code does not look simple and I think he
> >         volunteered
> >            to do it. 
> >
> Not a piece of cake, definitely, mostly because of the many possible
> ways the two things (vNUMA topology and automatic placement) can
> interact and influence each others.
> 
> >         However he has also been busy reviewing Xen RT patches so
> >            I figured he hasn't yet done that.
> >  
> Exactly. I'm actually mostly done with it, but it needs a bit of
> refining of a couple of rough edges, and for sure some testing, and,
> once posted, integration with the other toolstack changes Elena has done
> while addressing review comments, and then of course re-reviewing.
> 
> > Yes, Dario mentioned he will be working on this.
> >         
> And I was, but as Konrad guessed, reviewing and testing the RT
> scheduling stuff ate some time.
> 
> Also, consider that I'm about to disappear for at least two weeks,
> starting (most likely) from next Monday, for (good :-) ) family reasons.
> That means I probably won't be able to review/help with any future
> version of the series.
> 
> Of course I'm no maintainer, I know, so that is not a showstopper
> per-se. I'm just saying I think I could have been of help, while I
> probably won't. :-)
> 
> >          - Since it would interact with auto NUMA placement and expose
> >         new
> >            logic in libxl we run in the problem of the 'stable' API
> >         that we
> >            MUST preserve. That is a worry - and will require
> >         scrutinity.
> >         
> Indeed.
> 
> >          - What is the impact if the toolstack patches go in Xen 4.6?
> >
> FWIW, my personal opinion is that we better actually defer this to 4.6.
>  
> > Maybe maintainers will have more info about this. I am only aware of
> > that
> > vNUMA will not be supported by toolstack in 4.5, so some related work
> > will not be merged 
> > as vNUMA aware ballooning and HVM support (not sure if the last one is
> > happening though).
> >
> Yes, true, this is a rather basic building block of more general vNUMA
> support. However, this also mean that, even if we merge it, we would
> only have part of the picture in place for 4.5 anyway. I.e., we can work
> on 4.6 to have all the vNUMA bits and pieces, and make a really big fuss
> about that when releasing! :-)
> 
> This does not mean I would not have liked to have it there (given all
> the effort that Elena, and recently Wei, put into it), but I guess this
> is how software development work, isn't it? :-/
> 
> So, in summary, my take on this is: a lot of progress has been made,
> which was not obvious, at least at some point. It's not yet ready, but
> that only mean 4.6 will be a great release wrt vNUMA!! :-D


Yes! And it will give Elena some time to relax instead of hurridly have
to code and test all of this :-)

Elena, I am sorry - but based on the feedback I believe the best
course is to defer this to Xen 4.6.

> 
> 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-24 16:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-24  4:30 vnuma toolstack extension request Elena Ufimtseva
2014-09-24 15:15 ` Konrad Rzeszutek Wilk
2014-09-24 15:24   ` Elena Ufimtseva
2014-09-24 16:09     ` Dario Faggioli
2014-09-24 16:59       ` Konrad Rzeszutek Wilk [this message]
2014-09-24 17:08         ` Elena Ufimtseva

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=20140924165936.GB7354@laptop.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=dario.faggioli@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=ufimtseva@gmail.com \
    --cc=wei.liu2@citrix.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.