From: "Jan Beulich" Subject: Re: [Patch 2 of 2]: PV-domain SMP performance Linux-part Date: Fri, 19 Dec 2008 09:33:54 +0000 Message-ID: <494B7892.76E4.0078.0@novell.com> References: <494B5769.6030206@fujitsu-siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Juergen Gross , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 19.12.08 10:10 >>> >I haven't seen any win on any real world setup. So I remain unconvinced, = and >it'll need more than you alone championing the patch to get it in. There >have been no other general comments so far (Jan's have been about = specific >details). I think I'd generally welcome a change like this, but I'm not certain how = far I feel convinced that the submission meets one very basic criteria: avoidance of mis-use of the feature by a domain (simply stating that a = vCPU will be de-scheduled after 1ms anyway doesn't seem sufficient to me). This might need to include ways to differentiate between Dom0/DomU and/or CPU- vs IO-bound vCPU-s. Beyond that, it seems questionable that tying this to event delivery being disabled on the vCPU is very useful - Xen could do this on its own, = without needing a second flag. Having an extra flag really seems useful only when one can set it while holding spin locks, which at least the Linux part of = the patch doesn't seem to aim at. Jan