Re: [Libunwind-devel] unw_backtrace(): Performance slowdown for ARM?

[Luke Diamand]

On 16 January 2018 at 18:19, Dave Watson <address@hidden> wrote:
> On 01/16/18 09:34 AM, Luke Diamand wrote:
>> On 16 January 2018 at 03:33, Luke Diamand <address@hidden> wrote:
>> > Hi!
>> >
>> > I could be wrong about this, but I'm finding a roughly 10x slowdown on
>> > ARM between 1.2.1 and current HEAD (e1ca8748).
>> >
>> > I have a small test program here:
>> >
>> > https://gist.github.com/luked99/7c67d94da5c33cac5a1b41a500013355
>
> I think there is a similar perf test program under tests/, 'make perf'
>
>> >
>> > On my Raspberry Pi 2, this is getting ~180us to do a self-backtrace in
>> > 1.2.1 and around 1.8ms in HEAD.
>> >
>> > I tried running perf, and that seems to be saying that it is opening
>> > and closing files a lot.
>> >
>> > I also had a go at git bisecting, but there's a separate bug which was
>> > introduced and then fixed which caused it to segfault, which overlaps
>> > with this problem, along with some other performance regression fixes.
>> >
>> > 90d0d15c4ec3bb812dcb44c081757ebf6756cc6b didn't crash, but was slow.
>> > 2a5d1a629634b3225fccb1ed8a0a765bccc77f2e crashed.
>> > v1.2.1 is fast.
>> >
>> > I'm configuring with:
>> >
>> > CC=arm-linux-gnueabihf-gcc CFLAGS="-g" configure --disable-debug
>> > --host=arm-linux \
>> >     --enable-shared --disable-static --with-sysroot=/home/lgd/arm
>> > --enable-maintainer-mode \
>> >     --disable-debug-frame --disable-block-signals
>> >
>> > Any ideas as to what's going on?
>>
>> If do:
>>   export UNW_ARM_UNWIND_METHOD=4
>>
>> (so only use the exidx tables) then it drops from ~1ms to 95us.
>>
>> My image only has the exidx tables; it's built with gcc using
>> bog-standard compiler and linker options.
>>
>> $ objdump -S bt_perf
>> Idx Name          Size      VMA       LMA       File off  Algn
>> ....
>>  15 .ARM.extab    00000264  0000a7e8  0000a7e8  0000a7e8  2**2
>>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>>  16 .ARM.exidx    000002a0  0000aa4c  0000aa4c  0000aa4c  2**2
>>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>>  17 .eh_frame     00000004  0000acec  0000acec  0000acec  2**2
>>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>
> I didn't notice anything in particular looking at the commit logs.
> I'll try and repro when I get a chance

arm_find_proc_info() seems to start out trying eh_frame tables. Isn't
it always best on ARM to start looking in the exidx tables?