Re: Enhance perf to support KVM

From: Avi Kivity <avi@redhat.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: "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>,
	Arnaldo Carvalho de Melo <acme@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: Fri, 26 Feb 2010 17:06:53 +0200	[thread overview]
Message-ID: <4B87E38D.6020703@redhat.com> (raw)
In-Reply-To: <20100226142318.GE23422@elte.hu>

On 02/26/2010 04:23 PM, Ingo Molnar wrote:
> * Avi Kivity<avi@redhat.com>  wrote:
>
>    
>> On 02/26/2010 03:16 PM, Ingo Molnar wrote:
>>      
>>> * Avi Kivity<avi@redhat.com>   wrote:
>>>
>>>        
>>>>> That was not what i suggested tho. tools/kvm/ would work plenty fine.
>>>>>
>>>>>            
>>>> I'll wait until we have tools/libc and tools/X.  After all, they affect a
>>>> lot more people and are concerned with a lot more kernel/user interfaces
>>>> than kvm.
>>>>          
>>> So your answer can be summed up as: 'we wont do what makes sense
>>> technically because others suck even more' ?
>>>        
>> I can sum up your this remark as 'whenever you disagree with me, I will
>> rephrase your words to make you look like an idiot'.
>>      
> Two points:
>
> 1)
>
> You can try to ridicule me if you want,

I'd much prefer it if if no ridiculing was employed on either side.

>   but do you actually claim that my
> summary is inaccurate?
>
> I do claim it's a substantially accurate summary: you said you will (quote:)
> "wait with tools/kvm/ until we have tools/libc and tools/X".
>
> 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.
>    

There are arguments for libc to be developed in linux-2.6.git, and 
arguments against.  The fact is that they are not, so presumably the 
arguments against plus inertia outweigh the arguments for.

The same logic holds for kvm, except that there are less arguments for 
development in linux-2.6.git.  Only a small part of qemu is actually 
concerned with kvm; most of it is mucking around with X, emulating old 
devices, emulating instruction sets (irrelevant for tools/kvm) and doing 
boring managementy stuff.

Do we really want to add several hundered thousand lines to Linux, only 
a few thousand or of which talk to the kernel?

> 2)
>
> I used a question mark (the sentence was not a statement of fact), and you
> have no obligation to agree with the summary i provided.
>
>    

Thanks.  I hope you don't agree with it either.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.