* Avi Kivity <avi@xxxxxxxxxx> wrote:
> On 03/21/2010 09:06 PM, Ingo Molnar wrote:
> >* Avi Kivity<avi@xxxxxxxxxx> wrote:
> >
> >>>>[...] Second, from my point of view all contributors are volunteers
> >>>>(perhaps their employer volunteered them, but there's no difference from
> >>>>my perspective). Asking them to repaint my apartment as a condition to
> >>>>get a patch applied is abuse. If a patch is good, it gets applied.
> >>>This is one of the weirdest arguments i've seen in this thread. Almost all
> >>>the time do we make contributions conditional on the general shape of the
> >>>project. Developers dont get to do just the fun stuff.
> >>So, do you think a reply to a patch along the lines of
> >>
> >> NAK. Improving scalability is pointless while we don't have a decent GUI.
> >>I'll review you RCU patches
> >> _after_ you've contributed a usable GUI.
> >>
> >>?
> >What does this have to do with RCU?
>
> The example was rcuifying kvm which took place a bit ago. Sorry, it wasn't
> clear.
>
> > I'm talking about KVM, which is a Linux kernel feature that is useless
> > without a proper, KVM-specific app making use of it.
> >
> > RCU is a general kernel performance feature that works across the board.
> > It helps KVM indirectly, and it helps many other kernel subsystems as
> > well. It needs no user-space tool to be useful.
>
> Correct. So should I tell someone that has sent a patch that rcu-ified kvm
> in order to scale it, that I won't accept the patch unless they do some
> usability userspace work? say, implementing an eject button. That's what I
> understood you to mean.
Of course you could say the following:
' Thanks, I'll mark this for v2.6.36 integration. Note that we are not
able to add this to the v2.6.35 kernel queue anymore as the ongoing
usability work already takes up all of the project's maintainer and
testing bandwidth. If you want the feature to be merged sooner than that
then please help us cut down on the TODO and BUGS list that can be found
at XYZ. There's quite a few low hanging fruits there. '
Although this RCU example is 'worst' possible example, as it's a pure speedup
change with no functionality effect.
Consider the _other_ examples that are a lot more clear:
' If you expose paravirt spilocks via KVM please also make sure the KVM
tooling can make use of it, has an option for it to configure it, and
that it has sufficient efficiency statistics displayed in the tool for
admins to monitor.'
' If you create this new paravirt driver then please also make sure it can
be configured in the tooling. '
' Please also add a testcase for this bug to tools/kvm/testcases/ so we dont
repeat this same mistake in the future. '
I'd say most of the high-level feature work in KVM has tooling impact.
And note the important arguement that the 'eject button' thing would not occur
naturally in a project that is well designed and has a good quality balance.
It would only occur in the transitionary period if a big lump of lower-quality
code is unified with higher-quality code. Then indeed a lot of pressure gets
created on the people working on the high-quality portion to go over and fix
the low-quality portion.
Which, btw., is an unconditonally good thing ...
But even an RCU speedup can be fairly linked/ordered to more pressing needs of
a project.
Really, the unification of two tightly related pieces of code has numerous
clear advantages. Please give it some thought before rejecting it.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
