Re: [PATCH 2/2] ARC: don't align ret_from_exception function

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


>From: Vineet Gupta <vgupta@xxxxxxxxxxxx>
>Sent: Thursday, March 12, 2020 00:10
>To: Eugeniy Paltsev; linux-snps-arc@xxxxxxxxxxxxxxxxxxx
>Cc: linux-kernel@xxxxxxxxxxxxxxx; Alexey Brodkin
>Subject: Re: [PATCH 2/2] ARC: don't align ret_from_exception function
>On 3/11/20 1:58 PM, Eugeniy Paltsev wrote:
>>> I would like to keep it aligned.
>>> ARC700 definitely has penalty for unaligned branch targets, so it will definitely
>>> suffer there.
>> Do you know some exact numbers? I'm not an expert in ARC700 (fortunately =)
>I don't remember the exact numbers either.
>>> For HS, unaligned branch targets have no penalty (for the general case atleast),
>>> but if it does get unaligned, the entire entry prologue code will be - i.e. each
>>> one of the subsequent 130 or so instructions. That doesn't seem like a good idea
>>> in general to me.
>> I really don't insist about applying this patch but I don't understand your
>> argumentation about ARC HS like at all.
>I knew you would argue hence I already copy/pasted the start and end of the
>epilogue already in my prev reply which you didn't care to read thru.

Well, I beg to differ :)

>If you start counting instructions from <ret_from_exception> all the way to end of
><debug_marker_ds> there are over 130 instructions all of which can be rendered
>unaligned by your patch. What is worse is that this would be unpredictable: the
>unaligned case will mostly NOT happen, but a new compiler or some subtle code
>change could causing potentially side-effects we won't even know where to look.

I'm definitely missing something. Let's forget for a moment about our code
written in ASM and check the the binaries compiled from C sources.
The function is aligned by 4 bytes. However the function body contain the mix of
16 bit, 32 bit, 48 bit and 64 bit instructions. So we have huge amount of
instructions with size > 16 bit which are aligned by 16 bit.

I briefly checked our RPM but I don't see any note that it is OK to have
dozen of unaligned instructions but it is NOT OK to have a hundred of them.

So, what are your concerns based on?

>>> I faked it using a nop_s and the SYM_FUNC_START_NOALIGN( ) annotation and can see
>>> all instructions getting unaligned.
>> What is the problem with it? It's totally valid and fine for ARC HS to have instructions
>> aligned by 2 byte. Or are you talking about ARC700 again?
>Yes I know that already. It is fine in general as I explained earlier, but can
>potentially NOT when 130 instructions are unaligned.
>>> Before;
>>> 921238e4 <ret_from_exception>:
>>> 921238e4:    ld    r8,[sp,124]
>>> 921238e8:    bbit0.nt    r8,0x7,212
>>> ...
>>> 92123ac8:    rtie
>>> 92123acc <debug_marker_ds>:
>>> 92123acc:    ld    r2,[0x927d81d8]
>>> 92123ad4:    add    r2,r2,0x1
>>> 92123ad8:    st    r2,[0x927d81d8]
>>> 92123ae0:    bmskn    r11,r10,0xf
>>> 92123ae4:    sr    r11,[aux_irq_act]
>>> 92123ae8:    b    -140    ;92123a5c
>>> After:
>>> 9212393c:    nop_s
>>> 9212393e <ret_from_exception>:
>>> 9212393e:    ld    r8,[sp,124]
>>> 92123942:    bbit0.nt    r8,0x7,214
>>> ...
>>> 92123b22:    rtie
>>> 92123b26 <debug_marker_ds>:
>>> 92123b26:    ld    r2,[0x927d81d8]
>>> 92123b2e:    add    r2,r2,0x1
>>> 92123b32:    st    r2,[0x927d81d8]
>>> 92123b3a:    bmskn    r11,r10,0xf
>>> 92123b3e:    sr    r11,[aux_irq_act]
>>> 92123b42:    b    -138    ;92123ab6 <debug_marker_syscall>
>>> 92123b46:    nop_s
linux-snps-arc mailing list

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux