Re: [Qemu-devel] [PATCH v2 0/6] ARM: AREG0 conversion

From: Artyom Tarasenko <atar4qemu@gmail.com>
To: Laurent Desnogues <laurent.desnogues@gmail.com>
Cc: "Blue Swirl" <blauwirbel@gmail.com>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Lluís Vilanova" <vilanova@ac.upc.edu>,
	"Paul Brook" <paul@codesourcery.com>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH v2 0/6] ARM: AREG0 conversion
Date: Tue, 27 Mar 2012 21:59:23 +0200	[thread overview]
Message-ID: <CACXAS8ASst07kWTX9O1YjFXpDgzKrvtH69goroBo-pT2kWbf7w@mail.gmail.com> (raw)
In-Reply-To: <CABoDooPW=gDmSAtpEc1Oyk2iVvUs0vcxPHn-QjxtZMPui2seMQ@mail.gmail.com>

On Tue, Mar 27, 2012 at 7:01 PM, Laurent Desnogues
<laurent.desnogues@gmail.com> wrote:
> On Tue, Mar 27, 2012 at 6:48 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
>> On Tue, Mar 27, 2012 at 13:40, Laurent Desnogues
>> <laurent.desnogues@gmail.com> wrote:
>>> On Mon, Mar 26, 2012 at 7:02 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
>>> [...]
>>>> 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.  The ARM target uses way too
> many helpers, but that's another discussion :-)
>

Have you tried compiling without -fstack-protector-all as suggested by Lluís?
I observe a similar slowdown on a sparc target, and there compiling
without stack protection definitely helps.

Artyom

-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu