From: Florian Weimer <fweimer@redhat.com>
To: Dave Martin <Dave.Martin@arm.com>, Yao Qi <qiyaoltc@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org, libc-alpha@sourceware.org,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Marc Zyngier <Marc.Zyngier@arm.com>,
gdb@sourceware.org, Alan Hayward <alan.hayward@arm.com>,
Torvald Riegel <triegel@redhat.com>,
Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
Date: Wed, 30 Nov 2016 12:38:00 -0000 [thread overview]
Message-ID: <3e8afc5a-1ba9-6369-462b-4f5a707d8b8a@redhat.com> (raw)
In-Reply-To: <20161130120654.GJ1574@e103592.cambridge.arm.com>
On 11/30/2016 01:06 PM, Dave Martin wrote:
> I'm concerned here that there may be no sensible fixed size for the
> signal frame. We would make it ridiculously large in order to minimise
> the chance of hitting this problem again -- but then it would be
> ridiculously large, which is a potential problem for massively threaded
> workloads.
What's ridiculously large?
We could add a system call to get the right stack size. But as it
depends on VL, I'm not sure what it looks like. Particularly if you
need determine the stack size before creating a thread that uses a
specific VL setting.
> For setcontext/setjmp, we don't save/restore any SVE state due to the
> caller-save status of SVE, and I would not consider it necessary to
> save/restore VL itself because of the no-change-on-the-fly policy for
> this.
Okay, so we'd potentially set it on thread creation only? That might
not be too bad.
I really want to avoid a repeat of the setxid fiasco, where we need to
run code on all threads to get something that approximates the
POSIX-mandated behavior (process attribute) from what the kernel
provides (thread/task attribute).
> I'm not familiar with resumable functions/executors -- are these in
> the C++ standards yet (not that that would cause me to be familiar
> with them... ;) Any implementation of coroutines (i.e.,
> cooperative switching) is likely to fall under the "setcontext"
> argument above.
There are different ways to implement coroutines. Stack switching (like
setcontext) is obviously impacted by non-uniform register sizes. But
even the most conservative variant, rather similar to switch-based
emulation you sometimes see in C coroutine implementations, might have
trouble restoring the state if it just cannot restore the saved state
due to register size reductions.
Thanks,
Florian
next prev parent reply other threads:[~2016-11-30 12:38 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-25 19:39 Dave Martin
2016-11-25 19:39 ` [RFC PATCH 02/29] arm64: signal: factor frame layout and population into separate passes Dave Martin
2016-11-25 19:39 ` [RFC PATCH 03/29] arm64: signal: factor out signal frame record allocation Dave Martin
2016-11-25 19:39 ` [RFC PATCH 01/29] arm64: signal: Refactor sigcontext parsing in rt_sigreturn Dave Martin
2016-11-25 19:40 ` [RFC PATCH 04/29] arm64: signal: Allocate extra sigcontext space as needed Dave Martin
2016-11-25 19:40 ` [RFC PATCH 05/29] arm64: signal: Parse extra_context during sigreturn Dave Martin
2016-11-25 19:41 ` [RFC PATCH 18/29] arm64/sve: signal: Restore FPSIMD/SVE state in rt_sigreturn Dave Martin
2016-11-25 19:41 ` [RFC PATCH 16/29] arm64/sve: signal: Add SVE state record to sigcontext Dave Martin
2016-11-25 19:41 ` [RFC PATCH 24/29] arm64/sve: Discard SVE state on system call Dave Martin
2016-11-25 19:41 ` [RFC PATCH 17/29] arm64/sve: signal: Dump Scalable Vector Extension registers to user stack Dave Martin
2016-11-30 9:56 ` [RFC PATCH 00/29] arm64: Scalable Vector Extension core support Yao Qi
2016-11-30 12:07 ` Dave Martin
2016-11-30 12:22 ` Szabolcs Nagy
2016-11-30 14:10 ` Dave Martin
2016-11-30 12:38 ` Florian Weimer [this message]
2016-11-30 13:56 ` Dave Martin
2016-12-01 9:21 ` Florian Weimer
2016-12-01 10:30 ` Dave Martin
2016-12-01 12:19 ` Dave Martin
2016-12-05 10:44 ` Florian Weimer
2016-12-05 11:07 ` Szabolcs Nagy
2016-12-05 15:05 ` Dave Martin
2016-12-02 11:49 ` Dave Martin
2016-12-02 16:34 ` Florian Weimer
2016-12-02 16:59 ` Joseph Myers
2016-12-02 18:21 ` Dave Martin
2016-12-02 21:57 ` Joseph Myers
2016-12-02 21:56 ` Yao Qi
2016-12-05 15:12 ` Dave Martin
2016-12-05 22:42 ` Torvald Riegel
2016-12-06 14:46 ` Dave Martin
2016-11-30 10:08 ` Florian Weimer
2016-11-30 11:06 ` Szabolcs Nagy
2016-11-30 14:06 ` 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=3e8afc5a-1ba9-6369-462b-4f5a707d8b8a@redhat.com \
--to=fweimer@redhat.com \
--cc=Dave.Martin@arm.com \
--cc=Marc.Zyngier@arm.com \
--cc=alan.hayward@arm.com \
--cc=ard.biesheuvel@linaro.org \
--cc=christoffer.dall@linaro.org \
--cc=gdb@sourceware.org \
--cc=libc-alpha@sourceware.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=qiyaoltc@gmail.com \
--cc=triegel@redhat.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 read-only IMAP folder(s) and NNTP newsgroup(s).