lkml.org 
[lkml]   [2021]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2 03/13] sh: remove unaligned access for sh4a
From
Date
Hi Arnd!

On 5/14/21 2:22 PM, Arnd Bergmann wrote:
>> My Renesas SH4-Boards actually run an sh4a-Kernel, not an sh4-Kernel:
>>
>> root@tirpitz:~> uname -a
>> Linux tirpitz 5.11.0-rc4-00012-g10c03c5bf422 #161 PREEMPT Mon Jan 18 21:10:17 CET 2021 sh4a GNU/Linux
>> root@tirpitz:~>
>>
>> So, if this change reduces performance on sh4a, I would rather not merge it.
>
> It only makes a difference in very specific scenarios in which unaligned
> accesses are done in a fast path, e.g. when forwarding network packet
> at a high rate on a big-endian kernel (little-endian kernels wouldn't run into
> this on IP headers). If you have a use case for this machine on which the
> you can show a performance regression, I can add a patch on top to put
> the optimized sh4a get_unaligned_le32() back. Dropping this patch
> altogether would make the series much more complex because most of
> the associated code gets removed in the end.

Hmm, okay. But why does code which sits below arch/sh have to be removed anyway?

I don't fully understand why it poses any maintenance burden/

> As I mentioned, supporting "movua" in the compiler likely has a much
> larger impact on performance, as it would also help in user space, and
> it should improve the networking case on little-endian kernels by replacing
> the four separate byte loads/shift pairs with a movua plus a byteswap.

The problem is that - at least in Debian - we use the sh4 baseline while the kernel
supports both sh4 and sh4a, so we can't use any of these instructions in userland at
the moment.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

\
 
 \ /
  Last update: 2021-05-15 17:37    [W:0.135 / U:0.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site