Re: Xen is a feature

George Dunlap
2009-06-02T16:41:57Z

Thomas Gleixner wrote:
> Exactly that's the point. Adding dom0 makes life easier for a group of
> users who decided to use Xen some time ago, but what Ingo wants is
> technical improvement of the kernel.
>
> There are many features which have been wildly used in the distro
> world where developers tried to push support into the kernel with the
> same line of arguments.
>
> The kernel policy always was and still is to accept only those
> features which have a technical benefit to the code base.
>
I can appreciate the idea of resisting the pushing of random features.
Still, your definition of "improving Linux" is still lacking. Obviously
a new scheduler is taking something that's existing and improving it.
But adding a new filesystem, a new driver, or adding a new feature, such
as notifications, AIO, a new hardware architecture, or even KVM: How do
those classify as "technical improvement to the kernel" or "features
which have technical benefit to the code base" in a way that Xen does not?

If you mean "increases Linux's technical capability", and define Xen as
outside of Linux, then I think the definition is too small. After all,
allowing Linux to run on an ARM processor isn't increasing Linux'
technical capability, it's just allowing a new group of people (people
with ARM chips) to use Linux. It's the same with Xen.

No one disputes the idea that changes shouldn't be ugly; no one disputes
the idea that changes shouldn't introduce performance regressions. But
there are patchqueues that are ready, signed-off by other maintainers,
and which Ingo admits that he has no technical objections to, but
refuses to merge.

(His most recent "objection" is that he claims the currently existing
pv_ops infrastructure (which KVM and others benefit from as well as Xen)
introduces almost a 1% overhead on native in an mm-heavy
microbenchmark. So he refuses to merge feature Y (dom0 support) until
the Xen community helps technically unrelated existing feature X
(pv_ops) meets some criteria. So it has nothing to do with the quality
of the patches themselves.)

[Not qualified to speak to the specific technical objections.]
> I really have a hard time to see why dom0 support makes Linux more
> useful to people who do not use it. It does not improve the Linux
> experience of Joe User at all.
>
If Joe User uses Amazon, he benefits. If Joe User downloads an Ubuntu
or Debian distro, and the hosting providers were more secure and had to
do less work because dom0 was inlined, then he benefits because of the
lower cost / resources freed to do other things.

But what I was actually talking about is the number of people who don't
use it now but would use it if it were merged in. There hundreds of
thousands of instances running now, and more people are chosing to use
it at the moment, even though those who use it have the devil's choice
between doing patching or using a 3-year old kernel. How many more
would use it if it were in mainline?
> In fact it could be harmful to the average user, if it's merged in a
> crappy way that increases overhead, has a performance cost and draws
> away development and maintenance resources from other areas of the
> kernel.
>
No one is asking for something to be merged in a crappy way, or with
unacceptable performance cost. There are a number of patchqueues that
Ingo has no technical objections to, but which he still refuses to merge.

"Drawing away development and maintenance resources" is a cost/benefits
question, and Jeremy's main point was that there is a *high* benefit for
dom0 being merged into mainline. The same could be said of almost
anything: are you suggesting not accepting any more KVM code because it
might "draw away development and maintenance resources from other areas
of the kernel"?
> Aside of that it can also hinder the development of a properly
> designed hypervisor in Linux: 'why bother with that new stuff, it
> might be cleaner and nicer, but we have this Xen dom0 stuff
> already?'.
>
This argument doesn't make any sense. Would you advocate only having
one filesystem for fear that people would somehow be discouraged from
working on a new filesystem?

Even if that were a valid argument, it wouldn't apply in this situation.
KVM has plenty of mind-share, and the support of RedHat. Also, I'd
wager that it's a lot easier for a Linux kernel developer to get
involved in KVM than in Xen, because they're already familiar with
Linux. I don't think anyone working on KVM will be tempted to give up
just because Xen is also available, unless it becomes clear that
linux-as-hypervisor isn't the best technical solution; in which case,
moving to Xen would be the right thing to do anyway. Merging dom0 Xen
will in no way interfere with the development of KVM or other
linux-as-hypervisor projects.

The main point of Jeremy's e-mail was NOT to say, "Lots of people use
this so you should merge it." He's was responding to Xen being treated
like it had no benefit. It does have a benefit; it is a feature.

-George