All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Dave Martin <Dave.Martin@arm.com>
Cc: Julien Grall <julien@xen.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Zhang Lei <zhang.lei@jp.fujitsu.com>,
	Julien Grall <julien.grall@arm.com>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	Daniel Kiss <Daniel.Kiss@arm.com>
Subject: Re: [PATCH v5 1/2] arm64/sve: Don't disable SVE on syscalls return
Date: Thu, 19 Nov 2020 19:02:35 +0000	[thread overview]
Message-ID: <20201119190235.GK5554@sirena.org.uk> (raw)
In-Reply-To: <20201119182748.GN6882@arm.com>


[-- Attachment #1.1: Type: text/plain, Size: 2035 bytes --]

On Thu, Nov 19, 2020 at 06:27:50PM +0000, Dave Martin wrote:
> On Wed, Nov 18, 2020 at 05:52:01PM +0000, Mark Brown wrote:
> > On Wed, Nov 18, 2020 at 12:51:56PM +0000, Dave Martin wrote:

> > > I think I missed this point.  It doesn't sound quite right to me: how
> > > will we ever turn SVE persistently off for a task?

> > As mentioned in the cover letter (which I inherited from Julien, it's
> > been this way since v1) we don't currently, the proposal mentioned in
> > the cover letter is to turn it off after some number of syscalls.

> I think there are two levels of this:

> 1) Basically the same behaviour as today, but optimising the fast path
> of a non-scheduling syscall to avoid dumping and reloading the regs,
> while not making other things worse (i.e., we still want SVE to get
> turned off when appropriate).

> 2) Introducing some logic to try to make an educated guess about whether
> SVE should be on or off.

> It wasn't clear that (2) would really be any better in practice than
> static logic -- after all, other arches have adopted such a thing and
> then subsequently dumped it -- but I don't have a strong argument
> against it.

> I guess I'd prefer to see this arbitrary (if straightforward) policy as
> a second patch, separate from the shovelwork in (1).

Hrm, right.  I guess part of it here is that both behaviours are equally
arbatrary and the leaving it on behaviour just falls out of the rest of
the change in the same way that the existing behaviour just falls out of
the current implementation.  I suspect given the limited availability of
SVE hardware at present and some educated guess as to what it might be
used for that current systems will struggle to notice either way but
that'll change as the feature makes it's way into a wider range of
systems.  I think the clearest thing will be to leave this initial
change with similar behaviour to what it currently has and add another
patch with a policy for turning SVE off to the series, that'll separate
things in the review if nothing else.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

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

  reply	other threads:[~2020-11-19 19:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-06 19:35 [PATCH v5 0/2] arm64/sve: First steps towards optimizing syscalls Mark Brown
2020-11-06 19:35 ` [PATCH v5 1/2] arm64/sve: Don't disable SVE on syscalls return Mark Brown
2020-11-13 18:48   ` Catalin Marinas
2020-11-13 20:13     ` Mark Brown
2020-11-16 17:59       ` Dave Martin
2020-11-16 19:45         ` Mark Brown
2020-11-17 18:16           ` Dave Martin
2020-11-17 23:03             ` Mark Brown
2020-11-18 12:51               ` Dave Martin
2020-11-18 17:52                 ` Mark Brown
2020-11-19 18:27                   ` Dave Martin
2020-11-19 19:02                     ` Mark Brown [this message]
2020-11-06 19:35 ` [PATCH v5 2/2] arm64/sve: Rework SVE trap access to use TIF_SVE_NEEDS_FLUSH Mark Brown

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=20201119190235.GK5554@sirena.org.uk \
    --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 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.