From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.global.frontbridge.com", Issuer "Microsoft Secure Server Authority" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 29C422C00DD for ; Sat, 11 May 2013 05:23:32 +1000 (EST) Date: Fri, 10 May 2013 14:22:37 -0500 From: Scott Wood Subject: Re: [v1][KVM][PATCH 1/1] kvm:ppc:booehv: direct ISI exception to Guest To: Alexander Graf In-Reply-To: (from agraf@suse.de on Fri May 10 12:57:33 2013) Message-ID: <1368213757.19683.10@snotra> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Cc: Caraman Mihai Claudiu-B02008 , "kvm@vger.kernel.org" , Wood Scott-B07421 , "kvm-ppc@vger.kernel.org" , "tiejun.chen" , "linuxppc-dev@lists.ozlabs.org" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 05/10/2013 12:57:33 PM, Alexander Graf wrote: > Could you guys please collect performance data during the next weeks =20 > on both guest-directed ISIs as well as VF MMIOs (preferably with =20 > in-kernel MMIO), so that we can decide on the direction that's worth =20 > going towards? Collecting data on VF MMIO would require implementing it (or at least =20 salvaging and fixing some old code), which is not a high priority at =20 the moment. If we do implement VF in the future we could always undo =20 the direct ISI change, but it would still be nice to know if there's =20 any real benefit in the first place. FWIW, I doubt that the "more stress on HW TLB" will be significant. -Scott=