All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: will@kernel.org, catalin.marinas@arm.com
Cc: sam.tebbs@arm.com, linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/8] arm64: Optimise and update memcpy, user copy and string routines
Date: Tue, 15 Oct 2019 16:49:55 +0100	[thread overview]
Message-ID: <cover.1571073960.git.robin.murphy@arm.com> (raw)

[ Since I've taken over this series just for the final upstream polish,
  I've left Sam's original cover letter below. Other than cosmetic
  cleanups, I ended up squashing the original first patch since it had
  become overwhelmingly redundant, and dropping the memset patch where
  we'd both initially managed to overlook the sneaky use of a Q register.

  Linaro have kindly given us permission to contribute Cortex Strings
  updates to Linux under GPLv2, as per their original submission.

  Robin. ]

This patch series optimises the arm64 memcpy, copy_to_user, copy_from_user,
copy_in_user, memcmp, memmove, memset, strcmp, strlen and strncmp routines by
importing the latest Cortex Strings implementation.

The first patch renames and reimplements the existing macros to use offset
addressing and adds postindex versions for existing code that relies on this
variant. The second patch imports the Cortex Strings implementation and removes
the uao_{stp, ldp}_post macros introduced in the first patch as they are no
longer needed. The final patch updates the fixup handlers so that they can
calculate the remaining number of bytes to be copied without using postindex
addressing.

When testing (detailed below) these changes give the following speedups:
  * copy_from_user: 13.17%
  * copy_to_user: 4.8%
  * memcpy: 27.88%
  * copy_in_user: Didn't appear in the test results.

Testing was done by booting a kernel with the changed implementation and
doing perf record on a defconfig kernel build from within a 3GB ramdisk.
Then perf report was run on the generated data and the number of samples
spent in each routine was noted. This same process was repeated for a build
on the latest master.

The fault handler was updated to provide the faulting address in x15 if the
fixup handler offset has its LSB set. The user memcpy routines then use this
behaviour by adding one to their fixup handler offsets. This behaviour is
similar to that in the sparc fault handler.

Robin Murphy (1):
  arm64: Tidy up _asm_extable_faultaddr usage

Sam Tebbs (7):
  arm64: Allow passing fault address to fixup handlers
  arm64: Import latest Cortex Strings memcpy implementation
  arm64: Import latest version of Cortex Strings' memcmp
  arm64: Import latest version of Cortex Strings' memmove
  arm64: Import latest version of Cortex Strings' strcmp
  arm64: Import latest version of Cortex Strings' strlen
  arm64: Import latest version of Cortex Strings' strncmp

 arch/arm64/include/asm/alternative.h |  36 ---
 arch/arm64/include/asm/assembler.h   |  13 +
 arch/arm64/include/asm/extable.h     |  10 +-
 arch/arm64/lib/copy_from_user.S      | 103 ++++++--
 arch/arm64/lib/copy_in_user.S        | 106 ++++++--
 arch/arm64/lib/copy_template.S       | 304 ++++++++++-----------
 arch/arm64/lib/copy_template_user.S  |  24 ++
 arch/arm64/lib/copy_to_user.S        | 102 +++++--
 arch/arm64/lib/copy_user_fixup.S     |  14 +
 arch/arm64/lib/memcmp.S              | 317 ++++++++--------------
 arch/arm64/lib/memcpy.S              |  48 ++--
 arch/arm64/lib/memmove.S             | 236 ++++++-----------
 arch/arm64/lib/strcmp.S              | 278 ++++++++------------
 arch/arm64/lib/strlen.S              | 249 ++++++++++++------
 arch/arm64/lib/strncmp.S             | 379 ++++++++++++---------------
 arch/arm64/mm/extable.c              |  13 +-
 arch/arm64/mm/fault.c                |   2 +-
 17 files changed, 1125 insertions(+), 1109 deletions(-)
 create mode 100644 arch/arm64/lib/copy_template_user.S
 create mode 100644 arch/arm64/lib/copy_user_fixup.S

-- 
2.21.0.dirty


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

             reply	other threads:[~2019-10-15 15:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-15 15:49 Robin Murphy [this message]
2019-10-15 15:49 ` [PATCH 1/8] arm64: Allow passing fault address to fixup handlers Robin Murphy
2019-10-15 15:49 ` [PATCH 2/8] arm64: Import latest Cortex Strings memcpy implementation Robin Murphy
2019-10-15 15:49 ` [PATCH 3/8] arm64: Import latest version of Cortex Strings' memcmp Robin Murphy
2019-10-15 15:49 ` [PATCH 4/8] arm64: Import latest version of Cortex Strings' memmove Robin Murphy
2019-10-15 15:50 ` [PATCH 5/8] arm64: Import latest version of Cortex Strings' strcmp Robin Murphy
2019-10-15 15:50 ` [PATCH 6/8] arm64: Import latest version of Cortex Strings' strlen Robin Murphy
2019-10-15 15:50 ` [PATCH 7/8] arm64: Import latest version of Cortex Strings' strncmp Robin Murphy
2019-10-15 15:50 ` [PATCH 8/8] arm64: Tidy up _asm_extable_faultaddr usage Robin Murphy
2019-10-17 11:21 ` [PATCH 0/8] arm64: Optimise and update memcpy, user copy and string routines Catalin Marinas
2019-10-18  7:54 ` Catalin Marinas
2019-10-18  9:28   ` Robin Murphy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1571073960.git.robin.murphy@arm.com \
    --to=robin.murphy@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=sam.tebbs@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.