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

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



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

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