Re: KVM usability

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/02/2010 12:30 PM, Ingo Molnar wrote:
* Ingo Molnar<mingo@xxxxxxx>  wrote:

Here's our experience with tools/perf/. Hosting the project in the kernel
proper helped its quality immensely:

  - It's much easier to synchronize new features on the kernel side and on the
    user-space side. The two go hand in hand - they are often implemented in
    the same patch.
Just look at an example from today, a perf+KVM feature patch posted by Yanmin
Zhang:

   http://www.mail-archive.com/kvm@xxxxxxxxxxxxxxx/msg29770.html

That single patch implements the following "perf kvm" commands:

   perf kvm top
   perf kvm record
   perf kvm report
   perf kvm diff

Both the kernel-space and the user-space changes are in that single patch.

Anyone who'd like to try it out can apply it and get an updated kernel plus
updated tooling and can start profiling KVM guests straight away. You just
check out the kernel, apply the patch and that's it - you can go. It doesnt
get any more convenient than that to do development.

Such kind of a unified repository is a powerful concept, and we make use of
those aspects of tools/perf/ every day. You could only pry it out of our cold,
dead fingers ;-)

perf really is wonderful, but to be really competitive, and usable to more developers, it needs to be in a graphical environment. I want 'perf report' output to start out collapsed and drill down by clicking on a tree widget. Clicking on a function name opens its definition. 'perf annotate' should display annotations on my editor window, not in a pager. I should be able to check events on a list, not using 'perf list'.

Is something like that suitable for tools/perf/? I think you'll find the intersection of kernel developers and GUI developers to be fairly small.

Btw., this is one of the things that FreeBSD does right - and i believe it is
one of the technical concepts behind Apple's success as well. Apple, with a
tenth's of Linux's effective R&D budget can consistently out-develop Linux. I
think that's in part due to there not being a strict chinese wall between the
Apple kernel, libraries and applications - it's one coherent project where
everyone is well-connected to each piece, with no artificial project-cultural
boundaries and barriers. People can and do move between those areas of the
larger "Apple" project to achieve their goals - regardless of how many
components need touching for a given area of interest.

IMHO we should learn from that - while we are good in many areas there's
always aspects of Linux that can be improved. But i digress.

Folding everything into the kernel tree is one way to approach it; IMO it is completely unreasonable. The kernel is a very small part of a complete system.

--
error compiling committee.c: too many arguments to function

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

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux