From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50342) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6Fdq-0002K3-HK for qemu-devel@nongnu.org; Tue, 28 Aug 2012 02:51:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T6Fdo-0006wQ-Bt for qemu-devel@nongnu.org; Tue, 28 Aug 2012 02:51:14 -0400 Received: from mailout4.samsung.com ([203.254.224.34]:13517) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T6Fdo-0006wE-0A for qemu-devel@nongnu.org; Tue, 28 Aug 2012 02:51:12 -0400 Received: from epcpsbgm2.samsung.com (epcpsbgm2 [203.254.230.27]) by mailout4.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0M9G0022TDOUU7T0@mailout4.samsung.com> for qemu-devel@nongnu.org; Tue, 28 Aug 2012 15:51:07 +0900 (KST) Received: from [172.21.111.108] ([182.198.1.3]) by mmp2.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPA id <0M9G00KRQDP6KRJ0@mmp2.samsung.com> for qemu-devel@nongnu.org; Tue, 28 Aug 2012 15:51:07 +0900 (KST) Message-id: <503C6A98.7090906@samsung.com> Date: Tue, 28 Aug 2012 15:52:08 +0900 From: Yeongkyoon Lee MIME-version: 1.0 References: <1343201734-12062-1-git-send-email-yeongkyoon.lee@samsung.com> <1343201734-12062-4-git-send-email-yeongkyoon.lee@samsung.com> <500FFBE0.70700@twiddle.net> <50140795.5030209@samsung.com> <503B208D.2020407@samsung.com> In-reply-to: Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7bit Subject: Re: [Qemu-devel] [RFC][PATCH v4 3/3] tcg: Optimize qemu_ld/st by generating slow paths at the end of a block List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: laurent.desnogues@gmail.com, sw@weilnetz.de, Richard Henderson , qemu-devel@nongnu.org, peter.maydell@linaro.org >> It's been a long time. >> >> I've tested the performances of one jump difference when fast qemu_ld/st >> (TLB hit). >> The result shows 3.6% CoreMark enhancement when reducing one jump where slow >> paths are generated at the end of block as same for the both cases. >> That means reducing one jump dominates the majority of performance >> enhancement from LDST_OPTIMIZATION. >> As a result, it needs extended MMU helper functions for attaining that >> performance rising, and those extended functions are used only implicitly. >> >> BTW, who will finally confirm my patches? >> I have sent four version of my patches in which I have applied all the >> reasonable feedbacks from this community. >> Currently, v4 is the final candidate though it might need merge with latest >> HEAD because it was sent 1 month before. > I think the patches should be applied when 1.3 development opens. > Thanks for your reply. How do you estimate when 1.3 development is open?