Re: Enhance perf to support KVM

From: Arnaldo Carvalho de Melo <acme@infradead.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>, Avi Kivity <avi@redhat.com>,
	"Zhang, Yanmin" <yanmin_zhang@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	ming.m.lin@intel.com, sheng.yang@intel.com,
	Jes Sorensen <Jes.Sorensen@redhat.com>,
	KVM General <kvm@vger.kernel.org>,
	Zachary Amsden <zamsden@redhat.com>,
	Gleb Natapov <gleb@redhat.com>,
	Fr??d??ric Weisbecker <fweisbec@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arjan van de Ven <arjan@infradead.org>
Subject: Re: Enhance perf to support KVM
Date: Tue, 2 Mar 2010 14:12:50 -0300	[thread overview]
Message-ID: <20100302171250.GF4779@ghostprotocols.net> (raw)
In-Reply-To: <4B8D40CB.1090905@redhat.com>

Em Tue, Mar 02, 2010 at 05:46:03PM +0100, Paolo Bonzini escreveu:
> On 02/26/2010 03:23 PM, Ingo Molnar wrote:
>> I do think tools/X and tools/libc would make quite a bit of sense - this is
>> one of the better design aspects of FreeBSD et al. It's a mistake that it's
>> not being done.
>
> I don't see what it would buy to have tools/libc.  You cannot force  
> users to update kernel-space and user-space in lockstep (Apple forced  
> you to do that sometimes when I used Macs at work, and it was very very  
> inconvenient), so it's not like libc would be able to always assume the  
> latest system calls.  There is (relatively) a lot of  
> backwards-compatibility code in libc; it's ugly code, but you have to  
> live with it.
>
> Any case in which you need lockstep upgrades of kernel and libc for  
> bisectability is a bug in libc, and I haven't seen it happen enough to  
> be a problem.

You imply lockstep updates because both are on the same source tree? I
don't see why that would be required, there is an ABI contract to be
respected no matter where the sources for the signatories live.

perf lives in the kernel sources and while developing it I use all sorts
of combinations of userland and kernel perf bits so as not to be
rebooting the many machines of different arches where I test the
userspace bits all the time with a new kernel, even if it indeed has new
in-kernel perf bits.

As an instance where I could have worked on tools/libc recently was the
recvmmsg syscall I introduced.

Till it got into glibc (IIRC it was, but I wasn't involved in it, google
alert told me) interested parties had to use 'man syscall' and pick the
syscall number for their specific architecture, etc.

I could've done both the kernel and userspace bits in the same patch.

- Arnaldo