Re: [PATCH v5 12/17] xen/libxc: sched: DOMCTL_*vcpuaffinity works with hard and soft affinity

[George Dunlap <george.dunlap@eu.citrix.com>]

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