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

[Avi Kivity]

On 03/21/2010 11:52 PM, Ingo Molnar wrote:
> * 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.
>    

I am not arguing for a microkernel.  Again: reduce bloat where possible, 
kernel code is more expensive than userspace code.

> 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?
>    

I did not say that the amount of kernel and userspace code is the only 
factor deciding the quality of software.  If that were so, microkernels 
would have won out long ago.

It may be that that perf has too much kernel code, and won against 
oprofile despite that because it was better in other areas.  Or it may 
be that perf has exactly the right user/kernel division.  Or maybe perf 
needs some of the code moved from userspace to the kernel.  I don't 
know, I haven't examined the code.

The user/kernel boundary is only one metric for code quality.  Nor is it 
always in favour of pushing things to userspace.  Narrowing or 
simplifying an interface is often an argument in favour of pushing 
things into the kernel.

IMO the reason perf is more usable than oprofile has less to do with the 
kernel/userspace boundary and more do to with effort and attention spent 
on the userspace/user boundary.

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

Package costs are real.  We need to bear them.  I don't think that 
because maintaining another package (and the interface between two 
packages) is more difficult, then the kernel size should increase.

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

I'm not worried about 50K or so, I'm worried about a bug in those 50K 
taking down the guest.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

--
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/