Unify KVM kernel-space and user-space code into a single project
in [Kernel]
|
Prev: Irish 2010 Grant Winner
Next: [PATCH] staging: winbond: mds_f.h whitespace and CamelCase corrections.
From: Ingo Molnar on 22 Mar 2010 07:20 * Avi Kivity <avi(a)redhat.com> wrote: > On 03/21/2010 11:54 PM, Ingo Molnar wrote: > >* Avi Kivity<avi(a)redhat.com> wrote: > > > >>On 03/21/2010 10:55 PM, Ingo Molnar wrote: > >>>Of course you could say the following: > >>> > >>> ' Thanks, I'll mark this for v2.6.36 integration. Note that we are not > >>> able to add this to the v2.6.35 kernel queue anymore as the ongoing > >>> usability work already takes up all of the project's maintainer and > >>> testing bandwidth. If you want the feature to be merged sooner than that > >>> then please help us cut down on the TODO and BUGS list that can be found > >>> at XYZ. There's quite a few low hanging fruits there. ' > >>That would be shooting at my own foot as well as the contributor's since I > >>badly want that RCU stuff, and while a GUI would be nice, that itch isn't on > >>my back. > >I think this sums up the root cause of all the problems i see with KVM pretty > >well. > > I think we agree at last. Neither I nor my employer are interested in > running qemu as a desktop-on-desktop tool, therefore I don't invest any > effort in that direction, or require it from volunteers. Obviously your employer at least in part defers to you when it comes to KVM priorities. So, just to make this really clear, _you_ are not interested in running qemu as a desktop-on-desktop tool, subsequently this kind of disinterest-for-desktop-usability trickled through the whole KVM stack and poisoned your attitude and your contributor's attitude. Too sad really and it's doubly sad that you dont feel anything wrong about that. > If you think a good GUI is so badly needed, either write one yourself, or > convince someone else to do it. To a certain degree we are trying to do a small bit of that (see this very thread) - and you are NAK-ing and objecting the heck out of it via your unreasonable microkernelish and server-centric views. With constant maintainer disinterest there's no wonder a non-desktop-oriented KVM becomes a self-fulfilling prophecy: you think the desktop does not matter, hence it becomes a reality in KVM space which you can constantly refer back to as a 'fact'. Which i find dishonest and disingenious at best. > (btw, why are you interested in desktop-on-desktop? one use case is > developers, which don't really need fancy GUIs; a second is people who test > out distributions, but that doesn't seem to be a huge population; and a > third is people running Windows for some application that doesn't run on > Linux - hopefully a small catergory as well. Seems to be quite a small > target audience, compared to, say, video editing) I'm interested in desktop-on-desktop because i walk this world with open eyes and i care about Linux, and these days qemu-kvm is the first thing a new Linux user sees about Linux virtualization. I've observed several people i know in person to turn away from Linux and go back to Windows or go over to Apple because they had a much more mature solution. I'd probably turn away from Linux myself if i were a newbie and if i were forced to use KVM on the desktop today. Again, you dont seem to realize that you as a maintainer are at a central point where you have the ability to turn the self-fulfilling prophecy that 'nobody cares about the Linux desktop' into a reality - or where you have the ability to prevent it from happening. It is hugely harmful process, especially as you seem to delude yourself that you have nothing to do with it. Anyway, it's good you expressed your views about this as this will help the chances of a fresh restart. (which chances are still not too good though) Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 22 Mar 2010 07:30 * Avi Kivity <avi(a)redhat.com> wrote: > 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. > > [...] If you are interested in the first-hand experience of the people who are doing the perf work then here it is: by far the biggest reason for perf success and perf usability is the integration of the user-space tooling with the kernel-space bits, into a single repository and project. The very move you are opposing so vehemently for KVM. Oprofile went the way you proposed, and it was a failure. It failed not because it was bad technology (it was pretty decent and people used it), it was not a failure because the wrong people worked on it (to the contrary, very capable people worked on it), it was a failure in hindsight because it simply incorrectly split into two projects which stiffled the progress of each other. Obviously 3 years ago you'd have seen a similar, big "Oprofile is NOT broken!" flamewar, had i posted the same observations about Oprofile that i expressed about KVM here. (In fact there was a similar, big flamewar about all this when perf was posted a year ago.) And yes, (as you are aware of) i see very similar patterns of inefficiency in the KVM/Qemu tooling relationship as well, hence did i express my views about it. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 22 Mar 2010 07:50 * Avi Kivity <avi(a)redhat.com> wrote: > > My 10+ years experience with kernel instrumentation solutions is that > > kernel-driven, self-sufficient, robust, trustable, well-enumerated sources > > of information work far better in practice. > > What about line number information? And the source? Into the kernel with > them as well? Sigh. Please read the _very first_ suggestion i made, which solves all that. I rarely go into discussions without suggesting technical solutions - i'm not interested in flaming, i'm interested in real solutions. Here it is, repeated for the Nth time: Allow a guest to (optionally) integrate its VFS namespace with the host side as well. An example scheme would be: /guests/Fedora-G1/ /guests/Fedora-G1/proc/ /guests/Fedora-G1/usr/ /guests/Fedora-G1/.../ /guests/OpenSuse-G2/ /guests/OpenSuse-G2/proc/ /guests/OpenSuse-G2/usr/ /guests/OpenSuse-G2/.../ ( This feature would be configurable and would be default-off, to maintain the current status quo. ) Line number information and the source (dwarf info) and ELF symbols are all provided and accessible via such an interface - no need to run any 'symbol demon' on the guest side. And, obviously, having the guest VFS namespace (optionally) available on the host side also has far more uses than perf's symbol needs. I was surprised no-one ever came up with such a suggestion - it is so obvious to allow the integration of the VFS namespaces. But given your explicit declaration of your KVM desktop usability indifference i'm kind of not surprised about that anymore. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 22 Mar 2010 07:50 * Avi Kivity <avi(a)redhat.com> wrote: > On 03/21/2010 10:37 PM, Ingo Molnar wrote: > > > >>That includes the guest kernel. If you can deploy a new kernel in the > >>guest, presumably you can deploy a userspace package. > > > > Note that with perf we can instrument the guest with zero guest-kernel > > modifications as well. > > > > We try to reduce the guest impact to a bare minimum, as the difficulties > > in deployment are function of the cross section surface to the guest. > > > > Also, note that the kernel is special with regards to instrumentation: > > since this is the kernel project, we are doing kernel space changes, as we > > are doing them _anyway_. So adding symbol resolution capabilities would be > > a minimal addition to that - while adding a while new guest package for > > the demon would significantly increase the cross section surface. > > It's true that for us, changing the kernel is easier than changing the rest > of the guest. IMO we should still resist the temptation to go the easy path > and do the right thing (I understand we disagree about what the right thing > is). It is not about the 'temptation to go the easy path'. It is about finding the most pragmatic approach and realizing the cost of inaction: sucky Linux, sucky KVM. Let me give you an example: Linus's commit in v2.6.30 that changed the user-space policy of the EXT3 filesystem to make it more desktop capable: bbae8bc: ext3: make default data ordering mode configurable That changes was opposed vehemently with your kind of arguments: "such changes should be done by the distributions", "it should be done correctly", "the kernel should not implement policy", etc.. I can also tell you that this commit improved my desktop experience incredibly. Still, distros didnt do it for almost a decade of ext3 existence. Why? Truth is that those kinds of "do it right" arguments are mistaken because they assume that we live in an ideal, 'perfect market' where all inefficiencies will get eliminated in the long run. In reality the "market" for OSS software is imperfect: - there's marginal costs of action - a too small change has difficulty getting over that - there's costs of modularization (which are both technical and social) - there's the power of the status quo acting against marginally good changes - there's the power of entropy ripping Linux distributions apart making all-distro changes harder So the solution to the "why dont the distributions do this" question you pose is exactly what i propose: _give a default, reference implementation of KVM tooling that has to be eclipsed_. There's the unique position of the kernel that it can impose sanity in a more central way which acts as a reference implementation. I.e. the kernel can very much improve quality all across the board by providing a sane default (in the ext3 case) - or, as in the case of perf, by providing a sane 'baseline' tooling. It should do the same for KVM as well. If we dont do that, Linux will eventually stop mattering on the desktop - and some time after that, it will vanish from the server space as well. Then, may it be a decade down the line, you wont have a KVM hacking job left, and you wont know where all those forces eliminating your project came from. But i told you now so you'll know ;-) Reality is, the server space never was and never will be self-sustaining in the long run (as Novell has found it out with Netware), it is the desktop that dictates future markets. This is why i find your views about this naive and shortsighted. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 22 Mar 2010 08:00
* Anthony Liguori <anthony(a)codemonkey.ws> wrote: > On 03/21/2010 04:54 PM, Ingo Molnar wrote: > >* Avi Kivity<avi(a)redhat.com> wrote: > > > >>On 03/21/2010 10:55 PM, Ingo Molnar wrote: > >>>Of course you could say the following: > >>> > >>> ' Thanks, I'll mark this for v2.6.36 integration. Note that we are not > >>> able to add this to the v2.6.35 kernel queue anymore as the ongoing > >>> usability work already takes up all of the project's maintainer and > >>> testing bandwidth. If you want the feature to be merged sooner than that > >>> then please help us cut down on the TODO and BUGS list that can be found > >>> at XYZ. There's quite a few low hanging fruits there. ' > >>That would be shooting at my own foot as well as the contributor's since I > >>badly want that RCU stuff, and while a GUI would be nice, that itch isn't on > >>my back. > >I think this sums up the root cause of all the problems i see with KVM pretty > >well. > > A good maintainer has to strike a balance between asking more of people than > what they initially volunteer and getting people to implement the less fun > things that are nonetheless required. [...] Sorry to be blunt, but i dont think there's a different way to say it: i am a user of the software you are maintaining (Qemu) and i dont think you have the basis to educate people about what a good maintainer should do to achieve a quality end result. I think you could/should learn much from Linus and others who very much require quality to permeate the full dimension of a contribution (including usability), beyond the narrow, local scope of the contribution. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |