From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH v5 12/17] xen/libxc: sched: DOMCTL_*vcpuaffinity works with hard and soft affinity Date: Wed, 4 Dec 2013 15:49:36 +0000 Message-ID: <529F4F10.5040407@eu.citrix.com> References: <20131202180129.29026.81543.stgit@Solace> <20131202182908.29026.23720.stgit@Solace> <529DBA3F02000078001093CF@nat28.tlf.novell.com> <529DBB4A02000078001093E5@nat28.tlf.novell.com> <529E212C.8070205@eu.citrix.com> <1386095387.5338.361.camel@Solace> <529E24F7.90402@eu.citrix.com> <1386097618.3926.9.camel@Abyss> <1386147821.5338.394.camel@Solace> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VoEhv-0006WE-F4 for xen-devel@lists.xenproject.org; Wed, 04 Dec 2013 15:49:47 +0000 In-Reply-To: <1386147821.5338.394.camel@Solace> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli Cc: Marcus Granado , Justin Weaver , Matt Wilson , Li Yechen , Andrew Cooper , Juergen Gross , Ian Jackson , Jan Beulich , xen-devel , Keir Fraser , Elena Ufimtseva , Ian Campbell List-Id: xen-devel@lists.xenproject.org On 12/04/2013 09:03 AM, Dario Faggioli wrote: > On mar, 2013-12-03 at 20:06 +0100, Dario Faggioli wrote: >> On mar, 2013-12-03 at 18:37 +0000, George Dunlap wrote: >>> It is worth looking at the whole series again to try to see what the >>> risks are, and if it's still worth taking. I'll probably send something >>> out tomorrow. >>> >> Right. Since you pronounced yourself for the exception fairly early, I >> never include such analysis in further releases. I think it's on me to >> provide it, so I will do that (tomorrow too, so feel free to wait for >> mine, if you want). >> > So, risk-vs-benefits analysis. > > If this still was only per-vCPU NUMA affinity, as it started, there > would be no point in having it: no in-tree consumers, unlikely to be > noticed and used by actual users. However, the way we redesigned and put > it, makes it general enough to be interesting even independently from > NUMA. It now is quite an advanced feature which, as far as I know, not > many other OSes or hypervisors have, and it comes at a very reasonable > cost, in terms of amount of code and magnitude of infrastructural (in > the scheduling subsystem) changes. Actually, the latter is a > simplification wrt what we have now! > > Granted that it provides benefits, risks. I think there are two kinds of > risks: one is related bugs (of course), the other has to do with the > interface. > > Bugs wise, I tend to agree to what George said in his last e-mail. Most > of the hypervisor work which happens in 'common code' (i.e., will affect > people not using this feature) is just refactoring and rewiring various > bits and pieces. Most of the new code is in enabling the feature at Xen, > libxc and libxl level and bugs there, for one, shouldn't be too hard to > spot and fix (as it happened right during v5), and could only be > triggered from dom0 (domU creation or via the new toolstack command > being introduced). > > I think the (potential) interface issues are the more important. In > fact, the interface not being the optimal one (at the Xen and xc level) > and not getting much attention (at the libxl level) in the first > versions of the patch series is what brought us here, this late into > code freeze. My personal opinion is that we have finally reached a point > where the interface is consistent and easy to maintain and to extend in > a compatible way, where that is needed (see, for instance, the > conversation with Ian Campbell about xl options). I agree with the general description of the situation. I just went through all of the patches yesterday and tried to break down the "risk" by evaluating the complexity of the patch, the potential impact if there were a bug, and the "reviewer risk" (i.e., how well the reviewers seemed comfortable with the code / interface). (I'll paste in my notes below for those interested.) The patches are fairly straightforward, and the risk for most patches is fairly small and simple. The core patches I think it likely that the worst that could happen if there is a bug would be a performance regression. So from a pure code perspective, I think the risk is on the low side. The thing that is more risky is, as you say, the interface. It's still quite a bit in flux, particularly the command-line part. And as far as coolness -- while it is definitely a cool feature, I'm not sure it's so critical that it can't wait for the next release. If we really want to prioritize a stable, bug-free release, I think we'll probably have to say 'wait' at this point to the soft affinity feature. Other views are welcome. :-) -George