From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 817 invoked by alias); 5 Dec 2016 15:12:45 -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 789 invoked by uid 89); 5 Dec 2016 15:12:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=communicating, general-purpose, generalpurpose, vls X-Spam-User: qpsmtpd, 2 recipients X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 05 Dec 2016 15:12:38 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 20B45AD7; Mon, 5 Dec 2016 07:12:37 -0800 (PST) Received: from e103592.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8B4DA3F483; Mon, 5 Dec 2016 07:12:35 -0800 (PST) Date: Mon, 05 Dec 2016 15:12:00 -0000 From: Dave Martin To: Yao Qi Cc: Florian Weimer , libc-alpha@sourceware.org, Ard Biesheuvel , Marc Zyngier , gdb@sourceware.org, Christoffer Dall , Alan Hayward , Torvald Riegel , linux-arm-kernel@lists.infradead.org Subject: Re: [RFC PATCH 00/29] arm64: Scalable Vector Extension core support Message-ID: <20161205151232.GU1574@e103592.cambridge.arm.com> References: <7a35d1ae-73df-03a5-c9d6-1a52754acf25@redhat.com> <20161130120654.GJ1574@e103592.cambridge.arm.com> <20161202215646.s2xymph6d6jlyrv3@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161202215646.s2xymph6d6jlyrv3@localhost> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2016-12/txt/msg00012.txt.bz2 On Fri, Dec 02, 2016 at 09:56:46PM +0000, Yao Qi wrote: > On 16-11-30 12:06:54, Dave Martin wrote: > > So, my key goal is to support _per-process_ vector length control. > > > > From the kernel perspective, it is easiest to achieve this by providing > > per-thread control since that is the unit that context switching acts > > on. > > > > Hi, Dave, > Thanks for the explanation. > > > How useful it really is to have threads with different VLs in the same > > process is an open question. It's theoretically useful for runtime > > environments, which may want to dispatch code optimised for different > > VLs -- changing the VL on-the-fly within a single thread is not > > something I want to encourage, due to overhead and ABI issues, but > > switching between threads of different VLs would be more manageable. > > This is a weird programming model. I may not have explained that very well. What I meant is, you have two threads communicating with one another, say. Providing that they don't exchange data using a VL-dependent representation, it should not matter that the two threads are running with different VLs. This may make sense if a particular piece of work was optimised for a particular VL: you can pick a worker thread with the correct VL and dispatch the job there for best performance. I wouldn't expect this ability to be exploited except by specialised frameworks. > > However, I expect mixing different VLs within a single process to be > > very much a special case -- it's not something I'd expect to work with > > general-purpose code. > > > > Since the need for indepent VLs per thread is not proven, we could > > > > * forbid it -- i.e., only a thread-group leader with no children is > > permitted to change the VL, which is then inherited by any child threads > > that are subsequently created > > > > * permit it only if a special flag is specified when requesting the VL > > change > > > > * permit it and rely on userspace to be sensible -- easiest option for > > the kernel. > > Both the first and the third one is reasonable to me, but the first one > fit well in existing GDB design. I don't know how useful it is to have > per-thread VL, there may be some workloads can be implemented that way. > GDB needs some changes to support "per-thread" target description. OK -- I'll implement for per-thread for now, but this can be clarified later. Cheers ---Dave