Re: [RFC] Unify KVM kernel-space and user-space code into a singleproject

From: Ingo Molnar
Date: Sun Mar 21 2010 - 17:52:32 EST



* Avi Kivity <avi@xxxxxxxxxx> wrote:

> > I.e. you are arguing for microkernel Linux, while you see me as arguing
> > for a monolithic kernel.
>
> No. I'm arguing for reducing bloat wherever possible. Kernel code is more
> expensive than userspace code in every metric possible.

1)

One of the primary design arguments of the micro-kernel design as well was to
push as much into user-space as possible without impacting performance too
much so you very much seem to be arguing for a micro-kernel design for the
kernel.

I think history has given us the answer for that fight between microkernels
and monolithic kernels.

Furthermore, to not engage in hypotheticals about microkernels: by your
argument the Oprofile design was perfect (it was minimalistic kernel-space,
with all the complexity in user-space), while perf was over-complex (which
does many things in the kernel that could have been done in user-space).

Practical results suggest the exact opposite happened - Oprofile is being
replaced by perf. How do you explain that?

2)

In your analysis you again ignore the package boundary costs and artifacts as
if they didnt exist.

That was my main argument, and that is what we saw with oprofile and perf:
while maintaining more kernel-code may be more expensive, it sure pays off for
getting us a much better solution in the end.

And getting a 'much better solution' to users is the goal of all this, isnt
it?

I dont mind what you call 'bloat' per se if it's for a purpose that users find
like a good deal. I have quite a bit of RAM in most of my systems, having 50K
more or less included in the kernel image is far less important than having a
healthy and vibrant development model and having satisfied users ...

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/