Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1514898
| From | "Jason A. Donenfeld" <Jason@zx2c4.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access |
| Date | 2016-11-03 23:30 +0100 |
| Message-ID | <szyGe-1ul-21@gated-at.bofh.it> (permalink) |
| References | <szbTj-3Er-7@gated-at.bofh.it> <szeo9-55A-7@gated-at.bofh.it> <szkDg-O3-27@gated-at.bofh.it> <sztGx-6N2-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hi David,
On Thu, Nov 3, 2016 at 6:08 PM, David Miller <davem@davemloft.net> wrote:
> In any event no piece of code should be doing 32-bit word reads from
> addresses like "x + 3" without, at a very minimum, going through the
> kernel unaligned access handlers.
Excellent point. In otherwords,
ctx->r[0] = (le32_to_cpuvp(key + 0) >> 0) & 0x3ffffff;
ctx->r[1] = (le32_to_cpuvp(key + 3) >> 2) & 0x3ffff03;
ctx->r[2] = (le32_to_cpuvp(key + 6) >> 4) & 0x3ffc0ff;
ctx->r[3] = (le32_to_cpuvp(key + 9) >> 6) & 0x3f03fff;
ctx->r[4] = (le32_to_cpuvp(key + 12) >> 8) & 0x00fffff;
should change to:
ctx->r[0] = (le32_to_cpuvp(key + 0) >> 0) & 0x3ffffff;
ctx->r[1] = (get_unaligned_le32(key + 3) >> 2) & 0x3ffff03;
ctx->r[2] = (get_unaligned_le32(key + 6) >> 4) & 0x3ffc0ff;
ctx->r[3] = (get_unaligned_le32(key + 9) >> 6) & 0x3f03fff;
ctx->r[4] = (le32_to_cpuvp(key + 12) >> 8) & 0x00fffff;
> We know explicitly that these offsets will not be 32-bit aligned, so
> it is required that we use the helpers, or alternatively do things to
> avoid these unaligned accesses such as using temporary storage when
> the HAVE_EFFICIENT_UNALIGNED_ACCESS kconfig value is not set.
So the question is: is the clever avoidance of unaligned accesses of
the original patch faster or slower than changing the unaligned
accesses to use the helper function?
I've put a little test harness together for playing with this:
$ git clone git://git.zx2c4.com/polybench
$ cd polybench
$ make run
To test with one method, do as normal. To test with the other, remove
"#define USE_FIRST_METHOD" from the source code.
@René: do you think you could retest on your MIPS32r2 hardware and
report back which is faster?
And if anybody else has other hardware and would like to try, this
could be nice.
Regards,
Jason
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH] poly1305: generic C can be faster on chips with slow unaligned access "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-11-02 19:00 +0100
Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access Herbert Xu <herbert@gondor.apana.org.au> - 2016-11-02 21:20 +0100
Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access Sandy Harris <sandyinchina@gmail.com> - 2016-11-02 21:50 +0100
Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-11-02 22:10 +0100
Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access Herbert Xu <herbert@gondor.apana.org.au> - 2016-11-02 22:10 +0100
Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-11-02 22:30 +0100
Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access Herbert Xu <herbert@gondor.apana.org.au> - 2016-11-02 22:30 +0100
Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-11-02 23:10 +0100
Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access Herbert Xu <herbert@gondor.apana.org.au> - 2016-11-03 01:50 +0100
Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-11-03 08:30 +0100
Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access David Miller <davem@davemloft.net> - 2016-11-03 18:10 +0100
Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-11-03 23:30 +0100
Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access Eric Biggers <ebiggers@google.com> - 2016-11-04 18:40 +0100
Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-11-07 19:10 +0100
Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-11-07 19:30 +0100
Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access Eric Biggers <ebiggers@google.com> - 2016-11-07 19:40 +0100
Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-11-07 20:10 +0100
Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access Eric Biggers <ebiggers@google.com> - 2016-11-07 20:30 +0100
Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-11-07 20:50 +0100
[PATCH v2] poly1305: generic C can be faster on chips with slow unaligned access "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-11-07 20:20 +0100
[PATCH v3] poly1305: generic C can be faster on chips with slow unaligned access "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-11-07 20:50 +0100
[PATCH v4] poly1305: generic C can be faster on chips with slow unaligned access "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-11-07 21:00 +0100
Re: [PATCH v4] poly1305: generic C can be faster on chips with slow unaligned access Eric Biggers <ebiggers@google.com> - 2016-11-07 21:50 +0100
Re: [PATCH v4] poly1305: generic C can be faster on chips with slow unaligned access Martin Willi <martin@strongswan.org> - 2016-11-08 09:10 +0100
Re: [PATCH v4] poly1305: generic C can be faster on chips with slow unaligned access Eric Biggers <ebiggers@google.com> - 2016-11-08 18:30 +0100
csiph-web