From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34635) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a02U9-0001MW-N9 for qemu-devel@nongnu.org; Sat, 21 Nov 2015 02:21:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a02U6-0005uf-HF for qemu-devel@nongnu.org; Sat, 21 Nov 2015 02:21:25 -0500 Received: from [59.151.112.132] (port=14210 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a02U6-0005uT-3u for qemu-devel@nongnu.org; Sat, 21 Nov 2015 02:21:22 -0500 References: <1448016301-20944-1-git-send-email-caoj.fnst@cn.fujitsu.com> <20151120124452-mutt-send-email-mst@redhat.com> <564EFE27.5040203@cn.fujitsu.com> <20151120132622-mutt-send-email-mst@redhat.com> <564F0AC9.3030601@cn.fujitsu.com> <20151120152425-mutt-send-email-mst@redhat.com> From: Cao jin Message-ID: <56501BA0.30205@cn.fujitsu.com> Date: Sat, 21 Nov 2015 15:22:08 +0800 MIME-Version: 1.0 In-Reply-To: <20151120152425-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] PCI: minor performance optimization List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org On 11/20/2015 09:30 PM, Michael S. Tsirkin wrote: > On Fri, Nov 20, 2015 at 07:58:01PM +0800, Cao jin wrote: >> >> >> On 11/20/2015 07:26 PM, Michael S. Tsirkin wrote: >>> On Fri, Nov 20, 2015 at 07:04:07PM +0800, Cao jin wrote: >>>> >>>> >>>> On 11/20/2015 06:45 PM, Michael S. Tsirkin wrote: >>>>> On Fri, Nov 20, 2015 at 06:45:01PM +0800, Cao jin wrote: >>>>> >>>>>> 2. As spec says, each capability must be DWORD aligned, so an optimization can >>>>>> be done via Loop Unrolling. >>>>> >>>>> Why do we want to optimize it? >>>>> >>>> >>>> For tiny performance improvement via less loop. take pcie express >>>> capability(60 bytes at most) for example, it may loop 60 times, now we just >>>> need 15 times, a quarter of before. >>> >>> But who cares? This is not a data path operation. >> >> It is tiny thing I found when browsing code. When found there are several >> places looks like this, I think maybe it does good to qemu to do this and >> CCed to you because it don`t look like a simple trivial patch. >> >> So, hey Michael, if you don`t like this kind of optimization, that`t ok, >> forget it. But I think it make me little confused when determine which kind >> of patch should be CCed to you. > > Optimization patches should normally include performance numbers > if they are to be merged. > Try to come up with a benchmark and you will realize that the speed of > this function has no effect under even half way realistic conditions. > Maybe you are right. OK, will send the param check patch to the qemu-trivial >>>>> . >>>>> >>>> >>>> -- >>>> Yours Sincerely, >>>> >>>> Cao Jin >>> . >>> >> >> -- >> Yours Sincerely, >> >> Cao Jin > . > -- Yours Sincerely, Cao Jin