UPSTREAM: arm64: lib: improve copy_page to deal with 128 bytes at a time
authorWill Deacon <will.deacon@arm.com>
Tue, 2 Feb 2016 12:46:25 +0000 (12:46 +0000)
committerJeff Vander Stoep <jeffv@google.com>
Thu, 22 Sep 2016 20:38:22 +0000 (13:38 -0700)
commit297bf83fa4e7804c28c6d950f39dbd3860552cb9
treec6c026fa6f112973d0ca708c3b3b4276dceeab21
parentb5924f376a221ffa0ee64a4410aff54416c2fd2d
UPSTREAM: arm64: lib: improve copy_page to deal with 128 bytes at a time

We want to avoid lots of different copy_page implementations, settling
for something that is "good enough" everywhere and hopefully easy to
understand and maintain whilst we're at it.

This patch reworks our copy_page implementation based on discussions
with Cavium on the list and benchmarking on Cortex-A processors so that:

  - The loop is unrolled to copy 128 bytes per iteration

  - The reads are offset so that we read from the next 128-byte block
    in the same iteration that we store the previous block

  - Explicit prefetch instructions are removed for now, since they hurt
    performance on CPUs with hardware prefetching

  - The loop exit condition is calculated at the start of the loop

Signed-off-by: Will Deacon <will.deacon@arm.com>
Tested-by: Andrew Pinski <apinski@cavium.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Bug: 30369029
Patchset: kaslr-arm64-4.4

(cherry picked from commit 223e23e8aa26b0bb62c597637e77295e14f6a62c)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Change-Id: Icabd86bbecc60ad0d730ab796e33b8762cecb1fb
arch/arm64/lib/copy_page.S