This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [RFC PATCH 06/10] arm64/sve: Disallow VL setting for individual threads by default
- From: Dave Martin <Dave dot Martin at arm dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: linux-arch at vger dot kernel dot org, Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org, Ard Biesheuvel <ard dot biesheuvel at linaro dot org>, Marc Zyngier <Marc dot Zyngier at arm dot com>, gdb at sourceware dot org, Joseph Myers <joseph at codesourcery dot com>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>, linux-arm-kernel at lists dot infradead dot org, Alan Hayward <alan dot hayward at arm dot com>, Torvald Riegel <triegel at redhat dot com>, Christoffer Dall <christoffer dot dall at linaro dot org>
- Date: Mon, 16 Jan 2017 12:23:40 +0000
- Subject: Re: [RFC PATCH 06/10] arm64/sve: Disallow VL setting for individual threads by default
- Authentication-results: sourceware.org; auth=none
- References: <1484220369-23970-1-git-send-email-Dave.Martin@arm.com> <1484220369-23970-7-git-send-email-Dave.Martin@arm.com> <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