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 22 Mar 2010 16:20 On 03/22/2010 10:06 PM, Ingo Molnar wrote: > * Avi Kivity<avi(a)redhat.com> wrote: > > >> On 03/22/2010 09:20 PM, Ingo Molnar wrote: >> >>> * Avi Kivity<avi(a)redhat.com> wrote: >>> >>> >>>>> Lets look at the ${HOME}/.qemu/qmp/ enumeration method suggested by >>>>> Anthony. There's numerous ways that this can break: >>>>> >>>> I don't like it either. We have libvirt for enumerating guests. >>>> >>> Which has pretty much the same problems to the ${HOME}/.qemu/qmp/ solution, >>> obviously. >>> >> It doesn't follow. The libvirt daemon could/should own guests from all >> users. I don't know if it does so now, but nothing is preventing it >> technically. >> > It's hard for me to argue against a hypothetical implementation, but all > user-space driven solutions for resource enumeration i've seen so far had > weaknesses that kernel-based solutions dont have. > Correct. kernel-based solutions also have issues. >> If qemu hangs, the guest hangs a few milliseconds later. >> > I think you didnt understand my point. I am talking about 'perf kvm top' > hanging if Qemu hangs. > Use non-blocking I/O, report that guest as dead. No point in profiling it, it isn't making any progress. > With a proper in-kernel enumeration the kernel would always guarantee the > functionality, even if the vcpu does not make progress (i.e. it's "hung"). > > With this implemented in Qemu we lose that kind of robustness guarantee. > If qemu has a bug in the resource enumeration code, you can't profile one guest. If the kernel has a bug in the resource enumeration code, the system either panics or needs to be rebooted later. > And especially during development (when developers use instrumentation the > most) is it important to have robust instrumentation that does not hang along > with the Qemu process. > It's nice not to have kernel oopses either. So when code can be in userspace, that's where it should be. >> If qemu fails, you lose your guest. If libvirt forgets about a >> guest, you can't do anything with it any more. These are more >> serious problems than 'perf kvm' not working. [...] >> > How on earth can you justify a bug ("perf kvm top" hanging) with that there > are other bugs as well? > There's no reason for 'perf kvm top' to hang if some process is not responsive. That would be a perf bug. > Basically you are arguing the equivalent that a gdb session would be fine to > become unresponsive if the debugged task hangs. Fortunately ptrace is > kernel-based and it never 'hangs' if the user-space process hangs somewhere. > Neither gdb nor perf should hang. > This is an essential property of good instrumentation. > > So the enumeration method you suggested is a poor, sub-part solution, simple > as that. > Or, you misunderstood it. >> [...] Qemu and libvirt have to be robust anyway, we can rely on them. Like >> we have to rely on init, X, sshd, and a zillion other critical tools. >> > We can still profile any of those tools without the profiler breaking if the > debugged tool breaks ... > You can't profile without qemu. >>> By your argument it would be perfectly fine to implement /proc purely via >>> user-space, correct? >>> >> I would have preferred /proc to be implemented via syscalls called directly >> from tools, and good tools written to expose the information in it. When >> computers were slower 'top' would spend tons of time opening and closing all >> those tiny files and parsing them. Of course the kernel needs to provide >> the information. >> > (Then you'll be enjoyed to hear that perf has enabled exactly that, and that we > are working towards that precise usecase.) > Are you exporting /proc/pid data via the perf syscall? If so, I think that's a good move. -- 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 22 Mar 2010 16:30 On 03/23/2010 02:54 AM, Ingo Molnar wrote: > * Alexander Graf<agraf(a)suse.de> wrote >> Yes. I think the point was that every layer in between brings potential >> slowdown and loss of features. >> > Exactly. The more 'fragmented' a project is into sub-projects, without a > single, unified, functional reference implementation in the center of it, the > longer it takes to fix 'unsexy' problems like trivial usability bugs. > > Furthermore, another negative effect is that many times features are > implemented not in their technically best way, but in a way to keep them local > to the project that originates them. This is done to keep deployment latencies > and general contribution overhead down to a minimum. The moment you have to > work with yet another project, the overhead adds up. > > So developers rather go for the quicker (yet inferior) hack within the > sub-project they have best access to. > > Tell me this isnt happening in this space ;-) > Integration is hard, requires a wider set of technical skills and getting good test coverage becomes more difficult. But I agree that it is worth the effort, kvm could reap large rewards from putting a greater emphasis on integration (ala vbox) - no matter how it is achieved (cowardly not taking sides on implementation decisions like repository locations). Antoine > 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 22 Mar 2010 16:30 * Alexander Graf <agraf(a)suse.de> wrote: > > Furthermore, another negative effect is that many times features are > > implemented not in their technically best way, but in a way to keep them > > local to the project that originates them. This is done to keep deployment > > latencies and general contribution overhead down to a minimum. The moment > > you have to work with yet another project, the overhead adds up. > > I disagree there. Keeping things local and self-contained has been the UNIX > secret. It works really well as long as the boundaries are well defined. The 'UNIX secret' works for text driven pipelined commands where we are essentially programming via narrow ASCII input of mathematical logic. It doesnt work for a GUI that is a 2D/3D environment of millions of pixels, shaped by human visual perception of prettiness, familiarity and efficiency. > The problem we're facing is that we're simply lacking an active GUI / > desktop user development community. We have desktop users, but nobody feels > like tackling the issue of doing a great GUI project while talking to > qemu-devel about his needs. Have you made thoughts about why that might be so? I think it's because of what i outlined above - that you are trying to apply the "UNIX secret" to GUIs - and that is a mistake. A good GUI is almost at the _exact opposite spectrum_ of good command-line tool: tightly integrated, with 'layering violations' designed into it all over the place: look i can paste the text from an editor straight into a firefox form. I didnt go through any hiearchy of layers, i just took the shortest path between the apps! In other words: in a GUI the output controls the design, for command-line tools the design controls the output. It is no wonder Unix always had its problems with creating good GUIs that are efficient to humans. A good GUI works like the human brain, and the human brain does not mind 'layering violations' when that gets it a more efficient result. > > So developers rather go for the quicker (yet inferior) hack within the > > sub-project they have best access to. > > Well - not necessarily hacks. It's more about project boundaries. Nothing is > bad about that. You wouldn't want "ls" implemented in the Linux kernel > either, right? :-) I guess you are talking to the wrong person as i actually have implemented ls functionality in the kernel, using async IO concepts and extreme threading ;-) It was a bit crazy, but was also the fastest FTP server ever running on this planet. 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 16:40 * Anthony Liguori <anthony(a)codemonkey.ws> wrote: > On 03/22/2010 02:22 PM, Ingo Molnar wrote: > >>Transitive had a product that was using a KVM context to run their > >>binary translator which allowed them full access to the host > >>processes virtual address space range. In this case, there is no > >>kernel and there are no devices. > > > > And your point is that such vcpus should be excluded from profiling just > > because they fall outside the Qemu/libvirt umbrella? > > You don't instrument it the way you'd instrument an operating system so no, > you don't want it to show up in perf kvm top. Erm, why not? It's executing a virtualized CPU, so sure it makes sense to allow the profiling of it! It might even not be the weird case you mentioned by some competing virtualization project to Qemu ... So your argument is wrong on several technical levels, sorry. 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 22 Mar 2010 16:40
On 03/22/2010 10:21 PM, Ingo Molnar wrote: > * Alexander Graf<agraf(a)suse.de> wrote: > > >>> Furthermore, another negative effect is that many times features are >>> implemented not in their technically best way, but in a way to keep them >>> local to the project that originates them. This is done to keep deployment >>> latencies and general contribution overhead down to a minimum. The moment >>> you have to work with yet another project, the overhead adds up. >>> >> I disagree there. Keeping things local and self-contained has been the UNIX >> secret. It works really well as long as the boundaries are well defined. >> > The 'UNIX secret' works for text driven pipelined commands where we are > essentially programming via narrow ASCII input of mathematical logic. > > It doesnt work for a GUI that is a 2D/3D environment of millions of pixels, > shaped by human visual perception of prettiness, familiarity and efficiency. > Modularization is needed when a project exceeds the average developer's capacity. For kvm, it is logical to separate privileged cpu virtualization, from guest virtualization, from host management, from cluster management. >> The problem we're facing is that we're simply lacking an active GUI / >> desktop user development community. We have desktop users, but nobody feels >> like tackling the issue of doing a great GUI project while talking to >> qemu-devel about his needs. >> > Have you made thoughts about why that might be so? > > I think it's because of what i outlined above - that you are trying to apply > the "UNIX secret" to GUIs - and that is a mistake. > > A good GUI is almost at the _exact opposite spectrum_ of good command-line > tool: tightly integrated, with 'layering violations' designed into it all over > the place: > > look i can paste the text from an editor straight into a firefox form. I > didnt go through any hiearchy of layers, i just took the shortest path > between the apps! > Nope. You copied text from one application into the clipboard (or selection, or PRIMARY, or whatever ) and pasted text from the clipboard to another application. If firefox and your editor had to interact directly, all would be lost. See - there was a global (for the session) third party, and it wasn't the kernel. > In other words: in a GUI the output controls the design, for command-line > tools the design controls the output. > Not in GUIs that I've seen the internals of. > It is no wonder Unix always had its problems with creating good GUIs that are > efficient to humans. A good GUI works like the human brain, and the human > brain does not mind 'layering violations' when that gets it a more efficient > result. > The problem is that only developers are involved, not people who understand human-computer interaction (in many cases, not human-human interaction either). Another problem is that a good GUI takes a lot of work so you need a lot of committed resources. A third problem is that it isn't a lot of fun, at least not the 20% of the work that take 800% of the time. -- 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/ |