From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59591) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCcYV-0001uD-Qj for qemu-devel@nongnu.org; Tue, 27 Mar 2012 15:59:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SCcYT-0003cN-Sc for qemu-devel@nongnu.org; Tue, 27 Mar 2012 15:59:47 -0400 Received: from mail-qc0-f173.google.com ([209.85.216.173]:49455) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SCcYT-0003bG-MA for qemu-devel@nongnu.org; Tue, 27 Mar 2012 15:59:45 -0400 Received: by qcsc20 with SMTP id c20so226597qcs.4 for ; Tue, 27 Mar 2012 12:59:43 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <201203261405.13760.paul@codesourcery.com> From: Artyom Tarasenko Date: Tue, 27 Mar 2012 21:59:23 +0200 Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 0/6] ARM: AREG0 conversion List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laurent Desnogues Cc: Blue Swirl , Peter Maydell , =?ISO-8859-1?Q?Llu=EDs_Vilanova?= , Paul Brook , qemu-devel On Tue, Mar 27, 2012 at 7:01 PM, Laurent Desnogues wrote: > On Tue, Mar 27, 2012 at 6:48 PM, Blue Swirl wrote: >> On Tue, Mar 27, 2012 at 13:40, Laurent Desnogues >> wrote: >>> On Mon, Mar 26, 2012 at 7:02 PM, Blue Swirl wrot= e: >>> [...] >>>> At least stack protector is protecting more code than before (for >>>> example TLB miss handler), but could overhead from that amount to 5%? >>>> >>>> Otherwise there should be just a few extra register moves here and >>>> there, that should be cheap on modern processors. >>> >>> The extra moves might be cheap but their cost is obviously not 0: >>> on top of using extra CPU core resources, code size is increased >>> which results in more instruction cache misses. >>> >>> I didn't like the idea when we discussed it back in May, now it >>> looks like we have concrete evidence the speed impact is >>> measurable (though I'd like some more numbers than the rough >>> 5% estimate I gave). >> >> A clearly defined test case running on a host that does not adjust >> clock frequencies would be nice. It would be interesting to find out >> where exactly the slowdown comes from. >> >> Perhaps the access helpers ({helper,_}_{ld,st}{b,w,l}_mmu) generated >> by softmmu_template.h are the culprit. If so, they could be split from >> other code and moved to TCG back ends. That way the interface could be >> improved while keeping all other cleanups. > > I also get a slowdown running in user mode, so I don't think > improving the mmu ld/st will completely remove the issue. > In that case the slowdown comes from the extra move > instructions for helper calls. =A0The ARM target uses way too > many helpers, but that's another discussion :-) > Have you tried compiling without -fstack-protector-all as suggested by Llu= =EDs? I observe a similar slowdown on a sparc target, and there compiling without stack protection definitely helps. Artyom --=20 Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu