From: Mark Brown <broonie@kernel.org>
To: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>
Cc: Julien Grall <julien@xen.org>,
Zhang Lei <zhang.lei@jp.fujitsu.com>,
Julien Grall <julien.grall@arm.com>,
Mark Brown <broonie@kernel.org>,
Dave Martin <Dave.Martin@arm.com>,
linux-arm-kernel@lists.infradead.org,
Daniel Kiss <Daniel.Kiss@arm.com>
Subject: [PATCH v4 0/8] arm64/sve: First steps towards optimizing syscalls
Date: Fri, 28 Aug 2020 19:11:47 +0100 [thread overview]
Message-ID: <20200828181155.17745-1-broonie@kernel.org> (raw)
This is a first attempt to optimize the syscall path when the user
application uses SVE. The patch series was originally written by Julien
Grall but has been left for a long time, I've updated it to current
kernels and tried to address the pending review feedback that I found
(which was mostly documentation issues). I may have missed some things
there, apologies if I did, and one thing I've not yet done is produced a
diagram of the states the relevant TIF_ flags can have - I need to work
out a sensible format for that.
Per the syscall ABI, SVE registers will be unknown after a syscall. In
practice, the kernel will disable SVE and the registers will be zeroed
(except the first 128-bits of each vector) on the next SVE instruction.
In a workload mixing SVE and syscalls, this will result to 2 entry/exit
to the kernel per syscall as we trap on the first SVE access after the
syscall. This series aims to avoid the second entry/exit by zeroing the
SVE registers on syscall return with a twist when the task will get
rescheduled.
This implementation will have an impact on application using SVE
only once. SVE will now be turned on until the application terminates
(unless disabling it via ptrace). Cleverer strategies for choosing
between SVE and FPSIMD context switching are possible (see fpu_counter
for SH in mainline, or [1]), but it is difficult to assess the benefit
right now. We could improve the behaviour in the future as a selection
of mature hardware platforsm emerges that we can benchmark.
It is also possible to optimize the case when the SVE vector-length
is 128-bit (i.e the same size as the FPSIMD vectors). This could be
explored in the future.
Note that the last patch for the series is is not here to optimize syscall
but SVE trap access by directly converting in hardware the FPSIMD state
to SVE state. If there are an interest to have this optimization earlier,
I can reshuffle the patches in the series.
v4:
- Rebase onto v5.9-rc2
- Address review comments from Dave Martin, mostly documentation but
also some refactorings to ensure we don't check capabilities multiple
times and the addition of some WARN_ONs to make sure assumptions we
are making about what TIF_ flags can be set when are true.
v3:
- Rebased to current kernels.
- Addressed review comments from v2, mostly around tweaks in the
[1] https://git.sphere.ly/dtc/kernel_moto_falcon/commit/acc207616a91a413a50fdd8847a747c4a7324167
Julien Grall (8):
arm64/fpsimd: Update documentation of do_sve_acc
arm64/signal: Update the comment in preserve_sve_context
arm64/fpsimdmacros: Allow the macro "for" to be used in more cases
arm64/fpsimdmacros: Introduce a macro to update ZCR_EL1.LEN
arm64/sve: Implement a helper to flush SVE registers
arm64/sve: Implement a helper to load SVE registers from FPSIMD state
arm64/sve: Don't disable SVE on syscalls return
arm64/sve: Rework SVE trap access to use TIF_SVE_NEEDS_FLUSH
arch/arm64/include/asm/fpsimd.h | 5 ++
arch/arm64/include/asm/fpsimdmacros.h | 48 +++++++++++---
arch/arm64/include/asm/thread_info.h | 6 +-
arch/arm64/kernel/entry-fpsimd.S | 30 +++++++++
arch/arm64/kernel/fpsimd.c | 95 ++++++++++++++++++++++-----
arch/arm64/kernel/process.c | 1 +
arch/arm64/kernel/ptrace.c | 11 ++++
arch/arm64/kernel/signal.c | 19 +++++-
arch/arm64/kernel/syscall.c | 13 ++--
9 files changed, 188 insertions(+), 40 deletions(-)
base-commit: d012a7190fc1fd72ed48911e77ca97ba4521bccd
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2020-08-28 18:16 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-28 18:11 Mark Brown [this message]
2020-08-28 18:11 ` [PATCH v4 1/8] arm64/fpsimd: Update documentation of do_sve_acc Mark Brown
2020-08-28 18:11 ` [PATCH v4 2/8] arm64/signal: Update the comment in preserve_sve_context Mark Brown
2020-08-28 18:11 ` [PATCH v4 3/8] arm64/fpsimdmacros: Allow the macro "for" to be used in more cases Mark Brown
2020-09-21 12:38 ` Will Deacon
2020-09-21 16:53 ` Dave Martin
2020-09-21 18:09 ` Mark Brown
2020-09-22 13:51 ` Dave Martin
2020-09-22 13:59 ` Mark Brown
2020-09-22 14:07 ` Dave Martin
2020-08-28 18:11 ` [PATCH v4 4/8] arm64/fpsimdmacros: Introduce a macro to update ZCR_EL1.LEN Mark Brown
2020-08-28 18:11 ` [PATCH v4 5/8] arm64/sve: Implement a helper to flush SVE registers Mark Brown
2020-08-28 18:11 ` [PATCH v4 6/8] arm64/sve: Implement a helper to load SVE registers from FPSIMD state Mark Brown
2020-08-28 18:11 ` [PATCH v4 7/8] arm64/sve: Don't disable SVE on syscalls return Mark Brown
2020-09-21 12:36 ` Will Deacon
2020-09-21 18:03 ` Mark Brown
2020-09-22 14:03 ` Dave Martin
2020-09-22 16:04 ` Mark Brown
2020-08-28 18:11 ` [PATCH v4 8/8] arm64/sve: Rework SVE trap access to use TIF_SVE_NEEDS_FLUSH Mark Brown
2020-09-21 12:42 ` [PATCH v4 0/8] arm64/sve: First steps towards optimizing syscalls Will Deacon
2020-09-21 12:56 ` Mark Brown
2020-09-21 13:08 ` Will Deacon
2020-09-21 18:17 ` Will Deacon
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=20200828181155.17745-1-broonie@kernel.org \
--to=broonie@kernel.org \
--cc=Daniel.Kiss@arm.com \
--cc=Dave.Martin@arm.com \
--cc=catalin.marinas@arm.com \
--cc=julien.grall@arm.com \
--cc=julien@xen.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=will@kernel.org \
--cc=zhang.lei@jp.fujitsu.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).