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: Avi Kivity on 21 Mar 2010 16:20 On 03/21/2010 09:59 PM, Ingo Molnar wrote: > > 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. > It's only clearly inferior if you ignore every consideration against it. It's definitely not a deployment non-starter, see the tons of daemons that come with any Linux system. The basic ones are installed and enabled automatically during system installation. > 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. > Yes. I'm just not sure about the auto-enabling part. > 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. > So long as you define 'transparent' as in 'only the guest kernel is involved' or even 'only the guest and host kernels are involved' we aren't going to make a lot of progress. I oppose shoving random bits of functionality into the kernel, especially things that are in daily use. While us developers do and will use profiling extensively, it doesn't need sit in every guest's non-swappable .text. > 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. > You haven't heard any NAKs, only objections. If we discuss things perhaps we can achieve something that works for everyone. If we keep turning the flames higher that's unlikely. -- 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/
From: Antoine Martin on 21 Mar 2010 16:20 On 03/22/2010 03:11 AM, Avi Kivity wrote: > On 03/21/2010 10:08 PM, Olivier Galibert wrote: >> On Sun, Mar 21, 2010 at 10:01:51PM +0200, Avi Kivity wrote: >>> 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. >> Which userspace? Deploying *anything* in the guest can be a >> nightmare, including paravirt drivers if you don't have a natively >> supported in the OS virtual hardware backoff. > > That includes the guest kernel. If you can deploy a new kernel in the > guest, presumably you can deploy a userspace package. That's not always true. The host admin can control the guest kernel via "kvm -kernel" easily enough, but he may or may not have access to the disk that is used in the guest. (think encrypted disks, service agreements, etc) Antoine >> Deploying things in the >> host OTOH is business as usual. > > True. > >> And you're smart enough to know that. > > Thanks. > -- 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:30 On 03/21/2010 10:18 PM, Antoine Martin wrote: >> That includes the guest kernel. If you can deploy a new kernel in >> the guest, presumably you can deploy a userspace package. > > That's not always true. > The host admin can control the guest kernel via "kvm -kernel" easily > enough, but he may or may not have access to the disk that is used in > the guest. (think encrypted disks, service agreements, etc) There is a matching -initrd argument that you can use to launch a daemon. I believe that -kernel use will be rare, though. It's a lot easier to keep everything in one filesystem. -- 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/
From: Avi Kivity on 21 Mar 2010 16:30 On 03/21/2010 09:06 PM, Ingo Molnar wrote: > * 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? > The example was rcuifying kvm which took place a bit ago. Sorry, it wasn't clear. > 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. > Correct. So should I tell someone that has sent a patch that rcu-ified kvm in order to scale it, that I won't accept the patch unless they do some usability userspace work? say, implementing an eject button. That's what I understood you to mean. > 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. > That might hold, but the tool is usable at least for some people - it runs in production. The people running it won't benefit from an eject button or any usability improvement since they run it through a centralized management tool that hides everything. They will benefit from the scalability patches. Should I still make those patches conditional on scalability work that is of no interest to the submitter? > >>> 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. > kvm contains many sub-areas. I'm not going to tie unrelated things together like the GUI and sclability, configuration file format and emulator correctness, nested virtualization and qcow2 asynchronity, or other crazy combinations. People either leave en mass or become frustrated if they can't. I do reject patches touching a sub-area that I think need to be done in userspace, for example. That's not to say kvm development is random. We have a weekly conference call where regular contributors and maintainers of both qemu and kvm participate and where we decide where to focus. Sadly the issue of a qemu GUI is not raised often. Perhaps you can participate and voice your concerns. -- 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/
From: Ingo Molnar on 21 Mar 2010 16:40
* Avi Kivity <avi(a)redhat.com> wrote: > 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. [...] Only if you apply it as a totalitarian rule. Furthermore, the logical conclusion of _your_ line of argument (applied in a totalitarian manner) is that 'nothing should be built into the kernel'. I.e. you are arguing for microkernel Linux, while you see me as arguing for a monolithic kernel. Reality is that we are somewhere inbetween, we are neither black nor white: it's shades of grey. If we want to do a good job with all this then we observe subsystems, we see how they relate to the physical world and decide about how to shape them. We identify long-term changes and re-design modularization boundaries in hindsight - when we got them wrong initially. We dont try to rationalize the status-quo. Lets see one example of that thought process in action: Oprofile. We saw that the modularization of oprofile was a total nightmare: a separate kernel-space and a separate user-space component, which was in constant version friction. The ABI between them was stiffling: it was hard to change it (you needed to trickle that through the tool as well which was on a different release schedule, etc.e tc.) The result was sucky usability that never went beyond some basic 'you can do profiling' threshold. The subsystem worked well within that design box, and it was worked on by highly competent people - but it was still far, far away from the potential it could have achieved. So we observed those problems and decided to do something about it: - We unified the two parts into a single maintenance domain. There's the kernel-side in kernel/perf_event.c and arch/*/*/perf_event.c, plus the user-side in tools/perf/. The two are connected by a very flexible, forwards and backwards compatible ABI. - We moved much more code into the kernel, realizing that transparent and robust instrumentation should be offered instead of punting abstractions into user-space (which is in a disadvantaged position to implement system-wide abstractions). - We created a no-bullsh*t approach to usability. perf is by no means perfect, but it's written by developers for developers and if you report a bug to us we'll act on it before anything else. Furthermore the kernel developers do the user-space coding as well, so there's no chinese wall separating them. Kernel-space becomes aware of the intricacies of user-space and user-space developers become aware of the difficulties of kernel-space as well. It's a good mix in our experience. The thing is (and i doubt you are surprised that i say that), i see a similar situation with KVM. The basic parameters are comparable to Oprofile: it has a kernel-space component and a KVM-specific user-space. By all practical means the two are one and the same, but are maintained as different projects. I have followed KVM since its inception with great interest. I saw its good initial design, i tried it early on and even wrote various patches for it. So i care more about KVM than a random observer would, but this preference and passion for KVM's good technical sides does not cloud my judgement when it comes to its weaknesses. In fact the weaknesses are far more important to identify and express publicly, so i tend to concentrate on them. Dont take this as me blasting KVM, we both know the many good aspects of KVM. So, as i explained it earlier in greater detail the modularization of KVM into a separate kernel-space and user-space component is one of its worst current weaknesses, and it has become the main stiffling force in the way of a better KVM experience to users. That, IMO, is the 'weakest link' of KVM today and no matter how well the rest of KVM gets improved those nice bits all get unfairly ignored when the user cannot have a usable and good desktop experience and thinks that KVM is crappy. I think you should think outside the initial design box you have created 4 years ago, you should consider iterating the model and you should consider the alternative i suggested: move (or create) KVM tooling to tools/kvm/ and treat it as a single project from there on. 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/ |