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

[Ingo Molnar]

* Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote:

> On 03/18/2010 06:48 AM, Ingo Molnar wrote:
> >* Avi Kivity<avi@xxxxxxxxxx>  wrote:
> >
> >>On 03/18/2010 12:50 PM, Ingo Molnar wrote:
> >>>* Avi Kivity<avi@xxxxxxxxxx>   wrote:
> >>>
> >>>>>The moment any change (be it as trivial as fixing a GUI detail or as
> >>>>>complex as a new feature) involves two or more packages, development speed
> >>>>>slows down to a crawl - while the complexity of the change might be very
> >>>>>low!
> >>>>Why is that?
> >>>It's very simple: because the contribution latencies and overhead compound,
> >>>almost inevitably.
> >>It's not inevitable, if the projects are badly run, you'll have high
> >>latencies, but projects don't have to be badly run.
> >So the 64K dollar question is, why does Qemu still suck?
> 
> Why does Linux AIO still suck?  Why do we not have a proper interface in 
> userspace for doing asynchronous file system operations?

Good that you mention it, i think it's an excellent example.

The suckage of kernel async IO is for similar reasons: there's an ugly package 
separation problem between the kernel and between glibc - and between the apps 
that would make use of it.

( With the separated libaio it was made worse: there were 3 libraries to
  work with, and even less applications that could make use of it ... )

So IMO klibc is an arguably good idea - eventually hpa will get around posting 
it for upstream merging again. Then we could offer both new libraries much 
faster, and could offer things like comprehensive AIO used pervasively within 
existing APIs.

> Why don't we have an interface in userspace to do zero-copy transmit and 
> receive of raw network packets?
>
> The lack of a decent userspace API for asynchronous file system operations 
> is a huge usability problem for us.  Take a look at the complexity of our 
> -drive option.  It's all because the kernel gives us sucky interfaces.

If you had your bits in tools/kvm/ you could make a strong case for a good 
kaio implementation - coupled with an actual, working use-case. ( You could 
use the raw syscall even without klibc. )

We could see the arguments on lkml turn from:

   'do we want this and it will take years to propagate this into apps'

into something like:

   ' Exactly how much faster does kvm go? and I'd get is straight away with my
     next kernel update tomorrow? Wow! '

Ok, i exaggerated a bit - but you get the idea. It's a much different picture 
when kernel developers and maintainers see an actual use-case, _right in the 
kernel repo they work with every day_.

Currently there's a wall between kernel developers and user-space developers, 
and there's somewhat of an element of fear and arrogance on both sides. For 
efficient technology such walls needs torn down and people need a bit more 
experience with each other's areas.

	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/