From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34333) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y4sj8-0001wY-Bs for qemu-devel@nongnu.org; Sat, 27 Dec 2014 09:52:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y4sj4-00069l-37 for qemu-devel@nongnu.org; Sat, 27 Dec 2014 09:52:22 -0500 Sender: Paolo Bonzini Message-ID: <549EC79C.2090608@redhat.com> Date: Sat, 27 Dec 2014 15:52:12 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1419581126-12927-1-git-send-email-tiejun.chen@intel.com> <549D356A.4050506@parallels.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] kvm_irqchip_assign_irqfd: just set irqfd in case of kvm_irqfds_enabled() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , "Denis V. Lunev" Cc: QEMU Trivial , Tiejun Chen , QEMU Developers , kvm-devel On 26/12/2014 18:59, Peter Maydell wrote: > Mm, but once you're into such microoptimisations as this you really > need to have a good justification for the effort, in the form of > profiling measurements that indicate that this is a hot path. > In this case that seems pretty unlikely, because I'd expect all > the systems where we care about performance will support irqfds, > so we won't be taking the early-exit code path anyhow. (And > not supporting irqfds is leaving much more performance on the > table than we could possibly be talking about in this function.) Also, it's even possible for a compiler to figure this out. All in all, I don't see any advantage to this patch... Paolo