public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Richard Henderson <richard.henderson@linaro.org>
To: "Florian Weimer" <fweimer@redhat.com>, "Björn Töpel" <bjorn@kernel.org>
Cc: Darius Rad <darius@bluespec.com>,
	Vineet Gupta <vineetg@rivosinc.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Andrew Waterman <andrew@sifive.com>,
	stillson@rivosinc.com, Paul Walmsley <paul.walmsley@sifive.com>,
	anup@brainfault.org, atishp@atishpatra.org, guoren@kernel.org,
	Conor Dooley <conor.dooley@microchip.com>,
	greentime.hu@sifive.com, vincent.chen@sifive.com,
	andy.chiu@sifive.com, arnd@kernel.org,
	linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
	libc-alpha@sourceware.org, christoph.muellner@vrull.eu,
	Aaron Durbin <adurbin@rivosinc.com>,
	linux@rivosinc.com
Subject: Re: RISCV Vector unit disabled by default for new task (was Re: [PATCH v12 17/17] riscv: prctl to enable vector commands)
Date: Thu, 15 Dec 2022 07:33:53 -0800	[thread overview]
Message-ID: <24a1a812-95a9-ed97-abd1-c0ff259726d2@linaro.org> (raw)
In-Reply-To: <87h6xwdf5g.fsf@oldenburg.str.redhat.com>

On 12/15/22 04:28, Florian Weimer via Libc-alpha wrote:
> * Björn Töpel:
> 
>>> For SVE, it is in fact disabled by default in the kernel.  When a thread
>>> executes the first SVE instruction, it will cause an exception, the kernel
>>> will allocate memory for SVE state and enable TIF_SVE.  Further use of SVE
>>> instructions will proceed without exceptions.  Although SVE is disabled by
>>> default, it is enabled automatically.  Since this is done automatically
>>> during an exception handler, there is no opportunity for memory allocation
>>> errors to be reported, as there are in the AMX case.
>>
>> Glibc has an SVE optimized memcpy, right? Doesn't that mean that pretty
>> much all processes on an SVE capable system will enable SVE (lazily)? If
>> so, that's close to "enabled by default" (unless SVE is disabled system
>> wide).
> 
> Yes, see sysdeps/aarch64/multiarch/memcpy.c:
> 
>    static inline __typeof (__redirect_memcpy) *
>    select_memcpy_ifunc (void)
>    {
>      INIT_ARCH ();
>    
>      if (sve && HAVE_AARCH64_SVE_ASM)
>        {
>          if (IS_A64FX (midr))
>            return __memcpy_a64fx;
>          return __memcpy_sve;
>        }
>    
>      if (IS_THUNDERX (midr))
>        return __memcpy_thunderx;
>    
>      if (IS_THUNDERX2 (midr) || IS_THUNDERX2PA (midr))
>        return __memcpy_thunderx2;
>    
>      if (IS_FALKOR (midr) || IS_PHECDA (midr))
>        return __memcpy_falkor;
>    
>      return __memcpy_generic;
>    }
>    
> And the __memcpy_sve implementation actually uses SVE.
> 
> If there were a prctl to select the vector width and enable the vector
> extension, we'd have to pick a width in glibc anyway.

There *is* a prctl to adjust the SVE vector width, but glibc does not need to select 
because SVE dynamically adjusts to the currently enabled width.  The kernel selects a 
default width that fits within the default signal frame size.

The other thing of note for SVE is that, with the default function ABI all of the SVE 
state is call-clobbered, which allows the kernel to drop instead of save state across 
system calls.  (There is a separate vector function call ABI when SVE types are used.)

So while strcpy may enable SVE for the thread, the next syscall may disable it again.


r~

  reply	other threads:[~2022-12-15 15:33 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20220921214439.1491510-1-stillson@rivosinc.com>
     [not found] ` <20220921214439.1491510-17-stillson@rivosinc.com>
2022-12-09  5:16   ` Vineet Gupta
2022-12-09  6:27     ` Palmer Dabbelt
2022-12-09  7:42       ` Andrew Waterman
2022-12-09 10:02         ` Florian Weimer
2022-12-09 12:21           ` Darius Rad
2022-12-09 12:32             ` Florian Weimer
2022-12-09 12:42               ` Darius Rad
2022-12-09 13:04                 ` Florian Weimer
2022-12-09 17:21                   ` Palmer Dabbelt
2022-12-09 19:42                     ` Vineet Gupta
2022-12-09 19:58                       ` Andrew Waterman
2022-12-13 16:43                       ` Darius Rad
2022-12-14 20:07                         ` Vineet Gupta
2022-12-14 23:13                           ` Samuel Holland
2022-12-15  2:09                           ` Darius Rad
2022-12-15 11:48                             ` Björn Töpel
2022-12-15 12:28                               ` Florian Weimer
2022-12-15 15:33                                 ` Richard Henderson [this message]
2022-12-15 18:57                                   ` Vineet Gupta
2022-12-15 18:59                                     ` Andrew Pinski
2022-12-15 19:01                                       ` Andrew Pinski
2022-12-15 19:56                                     ` Richard Henderson
2022-12-09 13:58       ` Icenowy Zheng

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=24a1a812-95a9-ed97-abd1-c0ff259726d2@linaro.org \
    --to=richard.henderson@linaro.org \
    --cc=adurbin@rivosinc.com \
    --cc=andrew@sifive.com \
    --cc=andy.chiu@sifive.com \
    --cc=anup@brainfault.org \
    --cc=arnd@kernel.org \
    --cc=atishp@atishpatra.org \
    --cc=bjorn@kernel.org \
    --cc=christoph.muellner@vrull.eu \
    --cc=conor.dooley@microchip.com \
    --cc=darius@bluespec.com \
    --cc=fweimer@redhat.com \
    --cc=greentime.hu@sifive.com \
    --cc=guoren@kernel.org \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux@rivosinc.com \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=stillson@rivosinc.com \
    --cc=vincent.chen@sifive.com \
    --cc=vineetg@rivosinc.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).