Messages in this thread | | | Date | Mon, 22 Mar 2010 22:15:48 +0200 | From | Avi Kivity <> | Subject | Re: [RFC] Unify KVM kernel-space and user-space code into a single project |
| |
On 03/22/2010 10:06 PM, Ingo Molnar wrote: > * Avi Kivity<avi@redhat.com> wrote: > > >> On 03/22/2010 09:20 PM, Ingo Molnar wrote: >> >>> * Avi Kivity<avi@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.
| |