From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92365 invoked by alias); 2 Dec 2016 21:56:56 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 92328 invoked by uid 89); 2 Dec 2016 21:56:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=mixing, requesting X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-wm0-f66.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=/ays0eiDCP59YEIsQirM3ITdnlUHeTjzm30G/8XPuOQ=; b=bZQmt3MC0NxxHAIq2yfvsd/0/9hr4oujWDV6B8aRT5mQmhMY+NUO1ivYudbPfctFX/ D1aD+AJKHmbpmRB4wdYLENpgKZafji1afmqzXI1KuRhcEyvOQTaNMkPDnquq/PiBHSBX yxFZcS1PeuCTyLqOVHo/KAO6YP9LAArxv7Dlz/TAhM+Z8tr8l9gtAuq/dgEYMotYuWxe K26S7rS43ToKfUZLPZ1xCZe0DjsE+vVa2s/lr/rtskKQgChktevmhcbphUJskb6TgAbX I6GlkGL8DK9yqJTsFP3sJG1tEMLIWvRYLiyDIJZebxcfc7hM6+4TD3mlSL6lIuY44bib KhVw== X-Gm-Message-State: AKaTC00oMqVWxIeWiQovIVyWa3EMlOoLU/g19oiwdgfdtvSKrAZTuAAE6tgSeIajEScCuA== X-Received: by 10.28.169.4 with SMTP id s4mr4543953wme.65.1480715812199; Fri, 02 Dec 2016 13:56:52 -0800 (PST) Date: Fri, 02 Dec 2016 21:56:00 -0000 From: Yao Qi To: Dave Martin Cc: Florian Weimer , linux-arm-kernel@lists.infradead.org, libc-alpha@sourceware.org, Ard Biesheuvel , Marc Zyngier , gdb@sourceware.org, Alan Hayward , Torvald Riegel , Christoffer Dall Subject: Re: [RFC PATCH 00/29] arm64: Scalable Vector Extension core support Message-ID: <20161202215646.s2xymph6d6jlyrv3@localhost> References: <7a35d1ae-73df-03a5-c9d6-1a52754acf25@redhat.com> <20161130120654.GJ1574@e103592.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161130120654.GJ1574@e103592.cambridge.arm.com> User-Agent: NeoMutt/20161104 (1.7.1) X-SW-Source: 2016-12/txt/msg00074.txt.bz2 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. > 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. -- Yao