linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Dave.Martin@arm.com (Dave Martin)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 06/10] arm64/sve: Disallow VL setting for individual threads by default
Date: Mon, 16 Jan 2017 12:23:40 +0000	[thread overview]
Message-ID: <20170116122337.GN3699@e103592.cambridge.arm.com> (raw)
In-Reply-To: <20170116113439.GF28060@E107787-LIN>

On Mon, Jan 16, 2017 at 11:34:39AM +0000, Yao Qi wrote:
> On 17-01-12 11:26:05, Dave Martin wrote:
> > General-purpose code in userspace is not expected to work correctly
> > if multiple threads are allowed to run concurrently with different
> > vector lengths in a single process.
> > 
> > This patch adds an explicit flag PR_SVE_SET_VL_THREAD to request
> > this behaviour.  Without the flag, vector length setting is
> > permitted only for a single-threaded process (which matches the
> > expected usage model of setting the vector length at process
> > startup).

To be clear, PR_SVE_SET_VL_THREAD is not persistent, it just overrides
the default one-thread-per-process restriction for this prctl call.

The idea is that if someone writes some code to set the VL and then
moves the code to a multithreaded environment, by default it will stop
working.  This is a hint that some actual work is likely needed to
port their code to work with multiple threads.

> Hi Dave,
> PR_SVE_SET_VL_THREAD can be arch-independent, IMO, because prctl
> needs a scope.  Looks some of them are system-wide, some of them are
> about threads within the same process (like, PR_MPX_ENABLE_MANAGEMENT).
> IOW, PR_SVE_SET_VL_THREAD can be general flag, to indicate the scope
> of each new ptrcl command is per-thread.

This can't be backported to the existing prctls because that would
change their behaviour.   Rather, what each prctl applies (thread or
process) is part of the definition of that particular prctl.

Since there are no other prctl() calls that can apply per-thread or
per-process, or that differ only in this regard, is seems a bit esoteric
to try to apply this concept across all prctls... ?

Which prctl()s are system-wide?  I didn't see any, but I may have missed
something.

> I happen to see PR_SET_FP_MODE in man pages, which is about setting
> FP register modes in runtime.  It is a little similar to setting VL in
> this patch.  However the doc doesn't mention the effect or the scope
> of this command.

The various FP/SIMD twiddling prctls() all seem to be arch-specific.
PR_SET_FP_MODE only exists for mips.

Unless the semantics are really the same, I'm not too keen on an arm64
prctl with the same name.

Putting "ARM64" in the name of the new prctls might be clearer, but
nobody seemed to care so far...

Cheers
---Dave

  reply	other threads:[~2017-01-16 12:23 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-12 11:25 [RFC PATCH 00/10] arm64/sve: Add userspace vector length control API Dave Martin
2017-01-12 11:26 ` [RFC PATCH 01/10] prctl: Add skeleton for PR_SVE_{SET, GET}_VL controls Dave Martin
2017-01-12 11:26 ` [RFC PATCH 02/10] arm64/sve: Track vector length for each task Dave Martin
2017-01-12 11:26 ` [RFC PATCH 03/10] arm64/sve: Set CPU vector length to match current task Dave Martin
2017-01-12 11:26 ` [RFC PATCH 04/10] arm64/sve: Factor out clearing of tasks' SVE regs Dave Martin
2017-01-12 11:26 ` [RFC PATCH 05/10] arm64/sve: Wire up vector length control prctl() calls Dave Martin
2017-01-12 11:26 ` [RFC PATCH 06/10] arm64/sve: Disallow VL setting for individual threads by default Dave Martin
2017-01-16 11:34   ` Yao Qi
2017-01-16 12:23     ` Dave Martin [this message]
2017-01-12 11:26 ` [RFC PATCH 07/10] arm64/sve: Add vector length inheritance control Dave Martin
2017-01-16 12:27   ` Yao Qi
2017-01-16 13:34     ` Dave Martin
2017-01-12 11:26 ` [RFC PATCH 08/10] arm64/sve: ptrace: Wire up vector length control and reporting Dave Martin
2017-01-16 12:20   ` Yao Qi
2017-01-16 13:32     ` Dave Martin
2017-01-16 15:11       ` Yao Qi
2017-01-16 15:47         ` Pedro Alves
2017-01-16 16:31           ` Dave Martin
2017-01-17 10:03         ` Dave Martin
2017-01-17 13:31           ` Alan Hayward
2017-01-19 17:11             ` Dave Martin
2017-01-12 11:26 ` [RFC PATCH 09/10] arm64/sve: Enable default vector length control via procfs Dave Martin
2017-01-12 11:26 ` [RFC PATCH 10/10] Revert "arm64/sve: Limit vector length to 512 bits by default" Dave Martin

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=20170116122337.GN3699@e103592.cambridge.arm.com \
    --to=dave.martin@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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 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).