Message-ID: <20100322200617.GD3306@elte.hu>
Date:	Mon, 22 Mar 2010 21:06:17 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Avi Kivity <avi@...hat.com>
Cc:	Anthony Liguori <anthony@...emonkey.ws>,
	Pekka Enberg <penberg@...helsinki.fi>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Sheng Yang <sheng@...ux.intel.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	Marcelo Tosatti <mtosatti@...hat.com>,
	oerg Roedel <joro@...tes.org>,
	Jes Sorensen <Jes.Sorensen@...hat.com>,
	Gleb Natapov <gleb@...hat.com>,
	Zachary Amsden <zamsden@...hat.com>, ziteng.huang@...el.com,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Fr?d?ric Weisbecker <fweisbec@...il.com>,
	Gregory Haskins <ghaskins@...ell.com>
Subject: Re: [RFC] Unify KVM kernel-space and user-space code into a single
 project


* Avi Kivity <avi@...hat.com> wrote:

> On 03/22/2010 09:20 PM, Ingo Molnar wrote:
> >* Avi Kivity<avi@...hat.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.

> >>>  - Those special files can get corrupted, mis-setup, get out of sync, or can
> >>>    be hard to discover.
> >>>
> >>>  - The ${HOME}/.qemu/qmp/ solution suggested by Anthony has a very obvious
> >>>    design flaw: it is per user. When i'm root i'd like to query _all_ current
> >>>    guest images, not just the ones started by root. A system might not even
> >>>    have a notion of '${HOME}'.
> >>>
> >>>  - Apps might start KVM vcpu instances without adhering to the
> >>>    ${HOME}/.qemu/qmp/ access method.
> >>- it doesn't work with nfs.
> >So out of a list of 4 disadvantages your reply is that you agree with 3?
> 
> I agree with 1-3, disagree with 4, and add 5.  Yes.
> 
> >>>  - There is no guarantee for the Qemu process to reply to a request - while
> >>>    the kernel can always guarantee an enumeration result. I dont want 'perf
> >>>    kvm' to hang or misbehave just because Qemu has hung.
> >>If qemu doesn't reply, your guest is dead anyway.
> >Erm, but i'm talking about a dead tool here. There's a world of a difference
> >between 'kvm top' not showing new entries (because the guest is dead), and
> >'perf kvm top' hanging due to Qemu hanging.
> 
> 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.

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.

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.

> 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?

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.

This is an essential property of good instrumentation.

So the enumeration method you suggested is a poor, sub-part solution, simple 
as that.

> [...] 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 ...

> > 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.)

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists