On 03/18/2010 11:13 AM, Ingo Molnar wrote:
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.
And why wouldn't the kernel developers produce posix-aio within klibc.
posix-aio is also a really terrible interface (although not as bad as
linux-aio).
The reason boils down to the fact that these interfaces are designed
without interacting with the consumers. Part of the reason for that is
the attitude of the community.
You approached this discussion with, "QEMU/KVM sucks, you should move
into the kernel because we're awesome and we'd fix everything in a heart
beat". That attitude does not result in any useful collaboration.
Had you started trying to understand what the problems that we face are
and whether there's anything that can be done in the kernel to improve
it, it would have been an entirely different discussion.
The sad thing is, QEMU is probably one of the most demanding free
software applications out there today with respect to performance. We
consume interfaces IO interfaces and things like large pages in a deeper
way than just about any application out there.
We've been trying for a long time to improve Linux interfaces for years
but we've not had many people in the kernel community be receptive.
We've failed to improve the userspace networking interfaces. Compare
Rusty's posting of vringfd to vhost-net. They are the same interface
except we tried to do something more generally useful with vringfd and
it was shot down because it was "yet another kernel/userspace data
transfer interface". Unfortunately, we're learning that if we claim
something is virtualization specific, we avoid a lot of the kernel
bureaucracy. My concern is that over time, we'll have more things like
vhost and that's bad for everyone.
Regards,
Anthony Liguori
--
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
