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

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2684 bytes --]

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

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)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel