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 21 Mar 2010 15:10 * Avi Kivity <avi(a)redhat.com> wrote: > >> [...] Second, from my point of view all contributors are volunteers > >> (perhaps their employer volunteered them, but there's no difference from > >> my perspective). Asking them to repaint my apartment as a condition to > >> get a patch applied is abuse. If a patch is good, it gets applied. > > > > This is one of the weirdest arguments i've seen in this thread. Almost all > > the time do we make contributions conditional on the general shape of the > > project. Developers dont get to do just the fun stuff. > > So, do you think a reply to a patch along the lines of > > NAK. Improving scalability is pointless while we don't have a decent GUI. > I'll review you RCU patches > _after_ you've contributed a usable GUI. > > ? What does this have to do with RCU? I'm talking about KVM, which is a Linux kernel feature that is useless without a proper, KVM-specific app making use of it. RCU is a general kernel performance feature that works across the board. It helps KVM indirectly, and it helps many other kernel subsystems as well. It needs no user-space tool to be useful. KVM on the other hand is useless without a user-space tool. [ Theoretically you might have a fair point if it were a critical feature of RCU for it to have a GUI, and if the main tool that made use of it sucked. But it isnt and you should know that. ] Had you suggested the following 'NAK', applied to a different, relevant subsystem: | NAK. Improving scalability is pointless while we don't have a usable | tool. I'll review you perf patches _after_ you've contributed a usable | tool. you would have a fair point. In fact, we are doing that we are living by that. It makes absolutely zero sense to improve the scalability of perf if its usability sucks. So where you are trying to point out an inconsistency in my argument there is none. > > This is a basic quid pro quo: new features introduce risks and create > > additional workload not just to the originating developer but on the rest > > of the community as well. You should check how Linus has pulled new > > features in the past 15 years: he very much requires the existing code to > > first be top-notch before he accepts new features for a given area of > > functionality. > > For a given area, yes. [...] That is my precise point. KVM is a specific subsystem or "area" that makes no sense without the user-space tooling it relates to. You seem to argue that you have no 'right' to insist on good quality of that tooling - and IMO you are fundamentally wrong with that. 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 21 Mar 2010 15:20 * Anthony Liguori <anthony(a)codemonkey.ws> wrote: > On 03/19/2010 03:53 AM, Ingo Molnar wrote: > >* Avi Kivity<avi(a)redhat.com> wrote: > > > >>>There were two negative reactions immediately, both showed a fundamental > >>>server versus desktop bias: > >>> > >>> - you did not accept that the most important usecase is when there is a > >>> single guest running. > >>Well, it isn't. > >Erm, my usability points are _doubly_ true when there are multiple guests ... > > > >The inconvenience of having to type: > > > > perf kvm --host --guest --guestkallsyms=/home/ymzhang/guest/kallsyms \ > > --guestmodules=/home/ymzhang/guest/modules top > > > >is very obvious even with a single guest. Now multiply that by more guests ... > > If you want to improve this, you need to do the following: > > 1) Add a userspace daemon that uses vmchannel that runs in the guest and can > fetch kallsyms and arbitrary modules. If that daemon lives in > tools/perf, that's fine. Adding any new daemon to an existing guest is a deployment and usability nightmare. The basic rule of good instrumentation is to be transparent. The moment we have to modify the user-space of a guest just to monitor it, the purpose of transparent instrumentation is defeated. That was one of the fundamental usability mistakes of Oprofile. There is no 'perf' daemon - all the perf functionality is _built in_, and for very good reasons. It is one of the main reasons for perf's success as well. Now Qemu is trying to repeat that stupid mistake ... So please either suggest a different transparent solution that is technically better than the one i suggested, or you should concede the point really. Please try think with the heads of our users and developers and dont suggest some weird ivory-tower design that is totally impractical ... And no, you have to code none of this, we'll do all the coding. The only thing we are asking is for you to not stand in the way of good usability ... 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: Antoine Martin on 21 Mar 2010 15:50 On 03/22/2010 02:17 AM, Ingo Molnar wrote: > * Anthony Liguori<anthony(a)codemonkey.ws> wrote: > >> On 03/19/2010 03:53 AM, Ingo Molnar wrote: >> >>> * Avi Kivity<avi(a)redhat.com> wrote: >>> >>>>> There were two negative reactions immediately, both showed a fundamental >>>>> server versus desktop bias: >>>>> >>>>> - you did not accept that the most important usecase is when there is a >>>>> single guest running. >>>>> >>>> Well, it isn't. >>>> >>> Erm, my usability points are _doubly_ true when there are multiple guests ... >>> >>> The inconvenience of having to type: >>> >>> perf kvm --host --guest --guestkallsyms=/home/ymzhang/guest/kallsyms \ >>> --guestmodules=/home/ymzhang/guest/modules top >>> >>> is very obvious even with a single guest. Now multiply that by more guests ... >>> >> If you want to improve this, you need to do the following: >> >> 1) Add a userspace daemon that uses vmchannel that runs in the guest and can >> fetch kallsyms and arbitrary modules. If that daemon lives in >> tools/perf, that's fine. >> > Adding any new daemon to an existing guest is a deployment and usability > nightmare. > Absolutely. In most cases it is not desirable, and you'll find that in a lot of cases it is not even possible - for non-technical reasons. One of the main benefits of virtualization is the ability to manage and see things from the outside. > The basic rule of good instrumentation is to be transparent. The moment we > have to modify the user-space of a guest just to monitor it, the purpose of > transparent instrumentation is defeated. > Not to mention Heisenbugs and interference. Cheers Antoine > That was one of the fundamental usability mistakes of Oprofile. > > There is no 'perf' daemon - all the perf functionality is _built in_, and for > very good reasons. It is one of the main reasons for perf's success as well. > > Now Qemu is trying to repeat that stupid mistake ... > > So please either suggest a different transparent solution that is technically > better than the one i suggested, or you should concede the point really. > > Please try think with the heads of our users and developers and dont suggest > some weird ivory-tower design that is totally impractical ... > > And no, you have to code none of this, we'll do all the coding. The only thing > we are asking is for you to not stand in the way of good usability ... > > Thanks, > > Ingo > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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 21 Mar 2010 16:00 * Antoine Martin <antoine(a)nagafix.co.uk> wrote: > On 03/22/2010 02:17 AM, Ingo Molnar wrote: > >* Anthony Liguori<anthony(a)codemonkey.ws> wrote: > >>On 03/19/2010 03:53 AM, Ingo Molnar wrote: > >>>* Avi Kivity<avi(a)redhat.com> wrote: > >>>>>There were two negative reactions immediately, both showed a fundamental > >>>>>server versus desktop bias: > >>>>> > >>>>> - you did not accept that the most important usecase is when there is a > >>>>> single guest running. > >>>>Well, it isn't. > >>>Erm, my usability points are _doubly_ true when there are multiple guests ... > >>> > >>>The inconvenience of having to type: > >>> > >>> perf kvm --host --guest --guestkallsyms=/home/ymzhang/guest/kallsyms \ > >>> --guestmodules=/home/ymzhang/guest/modules top > >>> > >>>is very obvious even with a single guest. Now multiply that by more guests ... > >>If you want to improve this, you need to do the following: > >> > >>1) Add a userspace daemon that uses vmchannel that runs in the guest and can > >> fetch kallsyms and arbitrary modules. If that daemon lives in > >> tools/perf, that's fine. > > > > Adding any new daemon to an existing guest is a deployment and usability > > nightmare. > > Absolutely. In most cases it is not desirable, and you'll find that in a lot > of cases it is not even possible - for non-technical reasons. > > One of the main benefits of virtualization is the ability to manage and see > things from the outside. > > > The basic rule of good instrumentation is to be transparent. The moment we > > have to modify the user-space of a guest just to monitor it, the purpose > > of transparent instrumentation is defeated. > > Not to mention Heisenbugs and interference. Correct. Frankly, i was surprised (and taken slightly off base) by both Avi and Anthony suggesting such a clearly inferior "add a demon to the guest space" solution. It's a usability and deployment non-starter. Furthermore, allowing a guest to integrate/mount its files into the host VFS space (which was my suggestion) has many other uses and advantages as well, beyond the instrumentation/symbol-lookup purpose. So can we please have some resolution here and move on: the KVM maintainers should either suggest a different transparent approach, or should retract the NAK for the solution we suggested. We very much want to make progress and want to write code, but obviously we cannot code against a maintainer NAK, nor can we code up an inferior solution either. 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: Avi Kivity on 21 Mar 2010 16:10
On 03/21/2010 09:17 PM, Ingo Molnar wrote: > > Adding any new daemon to an existing guest is a deployment and usability > nightmare. > The logical conclusion of that is that everything should be built into the kernel. Where a failure brings the system down or worse. Where you have to bear the memory footprint whether you ever use the functionality or not. Where to update the functionality you need to deploy a new kernel (possibly introducing unrelated bugs) and reboot. If userspace daemons are such a deployment and usability nightmare, maybe we should fix that instead. > The basic rule of good instrumentation is to be transparent. The moment we > have to modify the user-space of a guest just to monitor it, the purpose of > transparent instrumentation is defeated. > You have to modify the guest anyway by deploying a new kernel. > Please try think with the heads of our users and developers and dont suggest > some weird ivory-tower design that is totally impractical ... > inetd.d style 'drop a listener config here and it will be executed on connection' should work. The listener could come with the kernel package, though I don't think it's a good idea. module-init-tools doesn't and people have survived somehow. > And no, you have to code none of this, we'll do all the coding. The only thing > we are asking is for you to not stand in the way of good usability ... > Thanks. -- 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(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/ |