From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117065 invoked by alias); 30 Nov 2016 12:38:36 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 117031 invoked by uid 89); 30 Nov 2016 12:38:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=policy X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 30 Nov 2016 12:38:33 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F3E3E804F2; Wed, 30 Nov 2016 12:38:31 +0000 (UTC) Received: from oldenburg.str.redhat.com (dhcp-192-212.str.redhat.com [10.33.192.212]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAUCcTPt028893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Nov 2016 07:38:30 -0500 Subject: Re: [RFC PATCH 00/29] arm64: Scalable Vector Extension core support To: Dave Martin , Yao Qi References: <20161130120654.GJ1574@e103592.cambridge.arm.com> Cc: linux-arm-kernel@lists.infradead.org, libc-alpha@sourceware.org, Ard Biesheuvel , Marc Zyngier , gdb@sourceware.org, Alan Hayward , Torvald Riegel , Christoffer Dall From: Florian Weimer Message-ID: <3e8afc5a-1ba9-6369-462b-4f5a707d8b8a@redhat.com> Date: Wed, 30 Nov 2016 12:38:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161130120654.GJ1574@e103592.cambridge.arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg00068.txt.bz2 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