From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) by sourceware.org (Postfix) with ESMTPS id 402323857C70 for ; Wed, 10 Nov 2021 11:40:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 402323857C70 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=bluespec.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=bluespec.com Received: by mail-qv1-xf29.google.com with SMTP id v2so1622382qve.11 for ; Wed, 10 Nov 2021 03:40:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bluespec-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=LxPuxMuQhZHJ80ASK5N7RtravzVMeaKzxtSHvwAEJtY=; b=y4JAJh4qCuBJUmEbDO+LIlqBgO0CDe4bqjnP7Fm67y1cqNUbyy4PiS1V3FnYOUX4g1 6UH1QOOiu0z9t/t7DdozkITH7MRjb5JpcfQgA8ZiouhCMdc4Mcu+V36OOJ/P1cae2YCf px7c+QIpCsNFN8JUCWrdkYrrOg+OyrWdNy+taVnnuTVEbqYtrj3AqXxFmIhgYRwwSWe8 8aZHnwl4bWlQ/iCDl222ILuXDKH7e3ZegwPz79rtAFUC0DbO+OxQOH//e4/LTXlZGoyA LmLu0R3vAUirvtj6V+4MjvLp8oJ1w62z148E9jcljkF6gD7sDgezH0Nqg/D5HtnwdGPF NIzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=LxPuxMuQhZHJ80ASK5N7RtravzVMeaKzxtSHvwAEJtY=; b=ITFKdfC8CbwtAOdsSpJPvzPpMgy1ukbc1akHPVzxhWUbykECdaznTIgFR6PfBoy5/f iBXUAZWsLLpdyBkv/EQrAFEVD67FH3CuUeT0Vh8FnZ7TmvJ9snAE6jCLnKOmNC9STHbw 32QvUuIUj+NPPsrWrD/CebxJzy22Y+q6ZM/Y6oJEp1jJ4Jv4+6WF0mVQCVY9fYZA7UsP M24Ro4X0gtWAwixG+8ZIJZFdeOQb1U+CF7pnbTRFyDgMCJX2jB2Z1ebDKidXuslTiiQd Cr8TxmBYrfcct/AveX7RP8VTv7z/fMrc1R5H7GAt9EgpKJA7WGYFDPZgz9YzEg/yyF+5 3xBw== X-Gm-Message-State: AOAM531s6mcyXr3oA+1PgHQK/WqfWeCPMgzNq2jn1NpHaBp9K5AsLsjk 5wXCfAJtXs9Pj+paq9+nTe2+ X-Google-Smtp-Source: ABdhPJzgiLRwAEq+j/jXrNqmWGCBhvuayUBmCwTt7gBb4/+ftuwQjIAVkBWDBwPA5m2TP3dpca90VA== X-Received: by 2002:ad4:5aa1:: with SMTP id u1mr15249417qvg.44.1636544399797; Wed, 10 Nov 2021 03:39:59 -0800 (PST) Received: from bruce.bluespec.com ([154.3.44.94]) by smtp.gmail.com with ESMTPSA id v3sm12634036qkd.20.2021.11.10.03.39.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Nov 2021 03:39:59 -0800 (PST) Date: Wed, 10 Nov 2021 06:39:57 -0500 From: Darius Rad To: Andrew Waterman Cc: Vincent Chen , libc-alpha@sourceware.org, Palmer Dabbelt , DJ Delorie Subject: Re: [RFC patch 0/5] RISC-V: Add vector ISA support Message-ID: Mail-Followup-To: Andrew Waterman , Vincent Chen , libc-alpha@sourceware.org, Palmer Dabbelt , DJ Delorie References: <1631497278-29829-1-git-send-email-vincent.chen@sifive.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, JMQ_SPF_NEUTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NEUTRAL autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2021 11:40:02 -0000 On Tue, Nov 09, 2021 at 02:18:17PM -0800, Andrew Waterman wrote: > On Tue, Nov 9, 2021 at 2:04 PM Darius Rad wrote: > > > > On Tue, Nov 09, 2021 at 11:30:49AM -0800, Andrew Waterman wrote: > > > On Tue, Nov 9, 2021 at 11:21 AM Darius Rad wrote: > > > > > > > > On Mon, Sep 13, 2021 at 09:41:13AM +0800, Vincent Chen wrote: > > > > > This patchset adds required ports to support RISC-V Vector (RVV) extension. > > > > > > > > > > Since the length of the vector register in RVV (the theoretical maximum > > > > > is 2^XLEN-1 bits) is variable, a huge and flexible space is needed to back > > > > > up all vector registers in the signal context. This patchset expands the > > > > > default SIGSTKSZ, MINSIGSTKSZ, and PTHREAD_STACK_MIN to ensure the stack > > > > > size is enough for the normal case (VLENB <= 128 bytes). Linux kernel also > > > > > places the exact minimum signal stack size in AT_MINSIGSTKSZ entry of the > > > > > auxiliary vector to inform user, so user still can know the sutible minimum > > > > > signal stack size by sysconf (_SC_MINSIGSTKSZ) if the VLENB is greater > > > > > than 128 bytes. > > > > > > > > > > In addition, according to the specification, the VCSR that combines VXRM and > > > > > VXSAT has thread storage duration, so this patchset adds the required user > > > > > context operation for it. > > > > > > > > > > Finally, the RISC-V glibc customized sigcontext.h has been removed in this > > > > > patchset. to reduce the synchronization work when new extension support is > > > > > introduced to the Linux environment. However, it may bring some backward > > > > > incompatible issues. Therefore, I sent an RFC patch > > > > > (https://sourceware.org/pipermail/libc-alpha/2020-June/115549.html) > > > > > to discuss this modification before this patchset. As I mentioned in the > > > > > RFC patch thread, I used OpenEmbeded to evaluate the impact. During the > > > > > tests, I didn't get any compiler errors. Therefore, I infer that this > > > > > modification may not cause server backward incompatible issues at this > > > > > moment. > > > > > > > > > > 1. The RISC-V V-extension draft v1.0 can be found in > > > > > https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc > > > > > 2. The associated kernel implementation can be found in > > > > > http://lists.infradead.org/pipermail/linux-riscv/2021-September/008249.html > > > > > 3. QEMU with RISC-V V-extension support can be found in > > > > > https://github.com/sifive/qemu/tree/rvv-1.0 > > > > > > > > > > > > > For the record on libc-alpha, I object to these changes. In particular, > > > > the lack of a user space API for the corresponding Linux support. More > > > > discussion on linux-riscv: > > > > > > > > https://lists.infradead.org/pipermail/linux-riscv/2021-September/thread.html#8361 > > > > > > I do not agree with that analysis. The vector extension scales down > > > to having potentially very little state (512 bytes on RV64) and we > > > expect typical applications-processor implementations to land in the > > > 512 - 2048-byte range. This matches AVX, not AMX. Furthermore, we > > > want all implementations to take advantage of vectorized C > > > string/memory functions without having to explicitly opt in. Not > > > doing this would put RISC-V at a significant competitive disadvantage > > > vs. other architectures with SIMD units. > > > > > > > The vector extension also scales up to 256 kiB, which, for comparison sake, > > is considerably more than AMX. > > We have good reason to believe that apps/server processors will not > get anywhere near an order of magnitude of that limit, and that huge > vector regfiles will be the province of HPC. > > > > > There are those that believe AVX should have had some sort of user space > > control [1], as well. > > > > [1] https://lore.kernel.org/lkml/87k0ntazyn.ffs@nanos.tec.linutronix.de/ > > > > I don't see how having user space control either prevents glibc from using > > vector by default when it is available or how it puts RISC-V at a > > significant competitive disadvantage. > > My "competitive advantage" comment was about the need to do the > following (quoting from your other message): > > "A process (or thread) must specifically request the desire to use > vector extensions (perhaps with some new arch_prctl() API)" > > I had assumed you meant that programmers must do this > explicitly--which would clearly put RISC-V at a competitive > disadvantage. If glibc initialization code makes this API call, then > I withdraw my comment. (But then I question the value of the API call > vs. the kernel automatically enabling the vector unit, since > essentially all processes will invoke the API call anyway.) The benefit to having the API call is that it allows the kernel to report a failure. This is necessary now, because memory allocation for context state can fail, and in some circumstances there is no other way to report that error. It is also useful for the future, as a way for the kernel to provide a policy enforcement mechanism whereby the system administrator can control which tasks are permitted to use vector extensions.