Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Martin <Dave.Martin@arm.com>
To: Julien Grall <julien.grall@arm.com>
Cc: Anton.Kirilov@arm.com, catalin.marinas@arm.com,
	will.deacon@arm.com, oleg@redhat.com, zhang.lei@jp.fujitsu.com,
	alex.bennee@linaro.org, linux-arm-kernel@lists.infradead.org,
	Daniel.Kiss@arm.com
Subject: Re: [RFC PATCH v2 0/8] arm64/sve: First steps towards optimizing syscalls
Date: Fri, 21 Jun 2019 16:32:17 +0100	[thread overview]
Message-ID: <20190621153217.GV2790@e103592.cambridge.arm.com> (raw)
In-Reply-To: <20190613161656.20765-1-julien.grall@arm.com>

On Thu, Jun 13, 2019 at 05:16:48PM +0100, Julien Grall wrote:
> Hi all,
> 
> This is a first attempt to optimize the syscall path when the user
> application uses SVE. The patch series is based on v5.2-rc4.
> 
> 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.
> 
> 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 [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 platform
> emerges that we can benchmark.

I'm wondering whether we ought to do something about this such as
turning SVE back off after the nth syscall.  Given the complexity of
this code though, let's stabilise the series as-is first.

I probably ask dumb questions in some places, since I'm trying to
refresh my memory of the subtleties of this code as I go...

> 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 respin of the series.
> 
> While developing the series, I have added a series of tracepoint in
> the SVE code. They may not be suitable for upstreaming and hence not
> included in the series. I can provide them if anyone is interested.
> 
> 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.

I think this could make sense.  Maybe see what Will and Catalin think
about it.

[...]

Cheers
---Dave

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

      parent reply	other threads:[~2019-06-21 15:32 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-13 16:16 [RFC PATCH v2 0/8] arm64/sve: First steps towards optimizing syscalls Julien Grall
2019-06-13 16:16 ` [RFC PATCH v2 1/8] arm64/fpsimd: Update documentation of do_sve_acc Julien Grall
2019-06-13 16:19   ` Julien Grall
2019-06-21 15:32   ` Dave Martin
2019-06-13 16:16 ` [RFC PATCH v2 2/8] arm64/signal: Update the comment in preserve_sve_context Julien Grall
2019-06-21 15:32   ` Dave Martin
2019-06-13 16:16 ` [RFC PATCH v2 3/8] arm64/fpsimdmacros: Allow the macro "for" to be used in more cases Julien Grall
2019-06-21 15:32   ` Dave Martin
2019-06-24 16:10     ` Julien Grall
2019-06-25  9:35       ` Dave Martin
2019-06-13 16:16 ` [RFC PATCH v2 4/8] arm64/fpsimdmacros: Introduce a macro to update ZCR_EL1.LEN Julien Grall
2019-06-21 15:32   ` Dave Martin
2019-06-13 16:16 ` [RFC PATCH v2 5/8] arm64/sve: Implement an helper to flush SVE registers Julien Grall
2019-06-21 15:33   ` Dave Martin
2019-06-24 16:28     ` Julien Grall
2019-06-25  9:37       ` Dave Martin
2019-06-13 16:16 ` [RFC PATCH v2 6/8] arm64/sve: Implement an helper to load SVE registers from FPSIMD state Julien Grall
2019-06-21 15:33   ` Dave Martin
2019-06-24 16:29     ` Julien Grall
2019-06-13 16:16 ` [RFC PATCH v2 7/8] arm64/sve: Don't disable SVE on syscalls return Julien Grall
2019-06-21 15:33   ` Dave Martin
2019-06-24 16:44     ` Julien Grall
2019-06-25  9:41       ` Dave Martin
2019-07-04 14:15     ` Catalin Marinas
2019-08-02 11:06       ` Julien Grall
2019-06-13 16:16 ` [RFC PATCH v2 8/8] arm64/sve: Rework SVE trap access to use TIF_SVE_NEEDS_FLUSH Julien Grall
2019-06-21 15:33   ` Dave Martin
2019-06-21 15:32 ` Dave Martin [this message]

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=20190621153217.GV2790@e103592.cambridge.arm.com \
    --to=dave.martin@arm.com \
    --cc=Anton.Kirilov@arm.com \
    --cc=Daniel.Kiss@arm.com \
    --cc=alex.bennee@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=julien.grall@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=oleg@redhat.com \
    --cc=will.deacon@arm.com \
    --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