From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: Enhance perf to support KVM Date: Fri, 26 Feb 2010 13:46:46 +0100 Message-ID: <20100226124646.GB19476@elte.hu> References: <1267068445.1726.25.camel@localhost> <1267089644.12790.74.camel@laptop> <1267152599.1726.76.camel@localhost> <20100226090147.GH15885@elte.hu> <4B879A2F.50203@redhat.com> <20100226103545.GA7463@elte.hu> <4B87A6BF.3090301@redhat.com> <20100226111734.GE7463@elte.hu> <4B87B407.2070309@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Zhang, Yanmin" , Peter Zijlstra , ming.m.lin@intel.com, sheng.yang@intel.com, Jes Sorensen , KVM General , Zachary Amsden , Gleb Natapov , Arnaldo Carvalho de Melo , Fr??d??ric Weisbecker , Thomas Gleixner , "H. Peter Anvin" , Peter Zijlstra , Arjan van de Ven To: Avi Kivity Return-path: Received: from mx2.mail.elte.hu ([157.181.151.9]:45988 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935858Ab0BZMrS (ORCPT ); Fri, 26 Feb 2010 07:47:18 -0500 Content-Disposition: inline In-Reply-To: <4B87B407.2070309@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: * Avi Kivity wrote: > > You basically have given up control over the quality of KVM by pushing so > > many aspects of it to user-space and letting it rot there. > > That's wrong on so many levels. First, nothing is rotting in userspace, > qemu is evolving faster than kvm is. If I pushed it into the kernel then > development pace would be much slower (since kernel development is harder), > quality would be lower (less infrastructure, any bug is a host crash or > security issue), and I personally would be totally swamped. That was not what i suggested tho. tools/kvm/ would work plenty fine. As i said: > > [...] You are pushing _way_ too much to user-space into different modules > > and maintenance domains, [...] > > > > ( Note that i dont mind user-space tooling per se, as long as it sits together > > with the kernel bits and gets developed, packaged and given to the user > > in the same domain. ) [...] > > Sure the design looks somewhat cleaner on paper, but if the end result is > > not helped by it then over-modularization sure can hurt ... > > Run 'rpm -qa' one of these days. Modern software is modular, that's the > only way to manage it. Of course rpm -qa shows cases where modularization works. But my point was over-modularization, which due to the KVM/qemu split we all suffer from. Modularizing along the wrong interface is worse than not modularizing something that could be. So when designing software you generally want to err on the side of _under_-modularizing. It's always very easy to split stuff up, when there's a really strong technical argument for it. It's very hard to pull the broken pieces back together though once they are in difference domains of maintanence - as then it's usually social integration that has to happen, which is always harder than a technical split-up. Ingo