From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Y5PBP-0005Dd-D9 for mharc-qemu-trivial@gnu.org; Sun, 28 Dec 2014 20:31:43 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46902) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5PBN-0005Bd-Gn for qemu-trivial@nongnu.org; Sun, 28 Dec 2014 20:31:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y5PBM-0001to-Kr for qemu-trivial@nongnu.org; Sun, 28 Dec 2014 20:31:41 -0500 Received: from mga01.intel.com ([192.55.52.88]:63223) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y5PBH-0001rm-Me; Sun, 28 Dec 2014 20:31:35 -0500 Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga101.fm.intel.com with ESMTP; 28 Dec 2014 17:31:33 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="505075742" Received: from tiejunch-mobl.ccr.corp.intel.com (HELO [10.238.130.48]) ([10.238.130.48]) by orsmga003.jf.intel.com with ESMTP; 28 Dec 2014 17:26:28 -0800 Message-ID: <54A0AEF2.3050300@intel.com> Date: Mon, 29 Dec 2014 09:31:30 +0800 From: "Chen, Tiejun" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Paolo Bonzini , Peter Maydell , "Denis V. Lunev" References: <1419581126-12927-1-git-send-email-tiejun.chen@intel.com> <549D356A.4050506@parallels.com> <549EC79C.2090608@redhat.com> In-Reply-To: <549EC79C.2090608@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 192.55.52.88 Cc: QEMU Trivial , QEMU Developers , kvm-devel Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH] kvm_irqchip_assign_irqfd: just set irqfd in case of kvm_irqfds_enabled() X-BeenThere: qemu-trivial@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 01:31:42 -0000 On 2014/12/27 22:52, Paolo Bonzini wrote: > > > 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... > Indeed, its just a cleanup to make codes readable and comprehensible since oftentimes we don't initially write such a subsequent code just because we have this possibility to figure them out by the compiler, or others. And this is why I'm CCing Qemu trivial. Tiejun From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [Qemu-devel] [PATCH] kvm_irqchip_assign_irqfd: just set irqfd in case of kvm_irqfds_enabled() Date: Mon, 29 Dec 2014 09:31:30 +0800 Message-ID: <54A0AEF2.3050300@intel.com> References: <1419581126-12927-1-git-send-email-tiejun.chen@intel.com> <549D356A.4050506@parallels.com> <549EC79C.2090608@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: QEMU Trivial , QEMU Developers , kvm-devel To: Paolo Bonzini , Peter Maydell , "Denis V. Lunev" Return-path: Received: from mga01.intel.com ([192.55.52.88]:47849 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751529AbaL2Bbd (ORCPT ); Sun, 28 Dec 2014 20:31:33 -0500 In-Reply-To: <549EC79C.2090608@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2014/12/27 22:52, Paolo Bonzini wrote: > > > 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... > Indeed, its just a cleanup to make codes readable and comprehensible since oftentimes we don't initially write such a subsequent code just because we have this possibility to figure them out by the compiler, or others. And this is why I'm CCing Qemu trivial. Tiejun