Message ID | 20230206194819.1679472-1-evan@rivosinc.com |
---|---|
Headers |
Return-Path: <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7305638555B6 for <patchwork@sourceware.org>; Mon, 6 Feb 2023 19:48:51 +0000 (GMT) X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) by sourceware.org (Postfix) with ESMTPS id CB6D33858C20 for <libc-alpha@sourceware.org>; Mon, 6 Feb 2023 19:48:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CB6D33858C20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-pg1-x535.google.com with SMTP id v3so8956188pgh.4 for <libc-alpha@sourceware.org>; Mon, 06 Feb 2023 11:48:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=6v9BqK9aVXhL+ZH5P/dhmv8KyUKdaPO9iNt1KqvTQTQ=; b=CnC5+TtQQR/lV15lkVgty5mrJsUzEu1blK5WSDY9vjzJaczpac0mud57NX3D2QwVYZ ux3QMyfwEBNq99ALA4IYgkWcrGfwMEnROqPSNcdzP06VbKoLX6Qv2NPrcBd82ZlO62bE kfP1Yrm4UEcmhm9y7YADYrtlHVLeSIHrwdGvyT2D4LvB+Dvia0oAjifJoOfZQTdq/EhP KS7kXgiLrHK3Th/3XrFmuMx6xOxsMvlQF0ueDP4vAYnB15PT5f2yYp6IhFTUFcRaaNne yP6wYh0nvvrajefhRrEtvmdz5JqJmM4G6UfBj2RFILXyTj2oQTFY+XCaBXlfVVGJskRw +SUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6v9BqK9aVXhL+ZH5P/dhmv8KyUKdaPO9iNt1KqvTQTQ=; b=p/ePDANDK0ZuEoabOlUlTl/slf0v90WSUT/Uru/OCEggtuul80rzOAilzdV1lDZRas avITfWlc7g07ek8I6R0oU9qJzPk8V/p29u5gxqetiz8hqKwXNcRvd2PC2c98JbBvlInL TQWzdB+Wl0PSvrJzTnPMUOXb7x77DDfache/B7aLqY08kfvjaRr7TVDHhsb8aMr7gexO s+Q2DHJiDYnuo4X9G5/3TwmRkacUTE/bP6iKY8ML/PDEkgmpjNDNXRS4Mz0h/M2y2vo3 av7I8l8U7DzM+f0/mf6UhljWYfIBnhKE7zN1dbDCPWH+xbtIL3TQui6aaBejdDEFO8+k RQyg== X-Gm-Message-State: AO0yUKUoX5425992xTtJ0iu8yLyvim6u0EsB5aQ69UULl0auKNp+iGD4 RC0NCST9JZz7PUMlDhars/f9ase7jDYAaXpzSJc= X-Google-Smtp-Source: AK7set/lmoFQ9XI7/zF4KvHQGiEbsN8Hdu1VoDKelVdvkPHP6KEPleKykuOCoL1a/58AmVPJDWmd8w== X-Received: by 2002:a62:1b43:0:b0:593:b0f7:873d with SMTP id b64-20020a621b43000000b00593b0f7873dmr598222pfb.19.1675712916442; Mon, 06 Feb 2023 11:48:36 -0800 (PST) Received: from evan.ba.rivosinc.com ([66.220.2.162]) by smtp.gmail.com with ESMTPSA id g20-20020aa796b4000000b0058bb0fb6295sm7512548pfk.26.2023.02.06.11.48.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Feb 2023 11:48:35 -0800 (PST) From: Evan Green <evan@rivosinc.com> To: libc-alpha@sourceware.org Cc: slewis@rivosinc.com, vineetg@rivosinc.com, palmer@rivosinc.com, Evan Green <evan@rivosinc.com> Subject: [PATCH 0/2] RISC-V: ifunced memcpy using new kernel hwprobe interface Date: Mon, 6 Feb 2023 11:48:17 -0800 Message-Id: <20230206194819.1679472-1-evan@rivosinc.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
RISC-V: ifunced memcpy using new kernel hwprobe interface
|
|
Message
Evan Green
Feb. 6, 2023, 7:48 p.m. UTC
This series illustrates the use of a proposed Linux syscall that enumerates architectural information about the RISC-V cores the system is running on. In this series we expose a small wrapper function around the syscall. An ifunc selector for memcpy queries it to see if unaligned access is "fast" on this hardware. If it is, it selects a newly provided implementation of memcpy that doesn't work hard at aligning the src and destination buffers. This is somewhat of a proof of concept for the syscall itself, but I do find that in my goofy memcpy test [1], the unaligned memcpy performed at least as well as the generic C version. This is however on Qemu on an M1 mac, so not a test of any real hardware (more a smoke test that the implementation isn't silly). v1 of the Linux series can be found at [2]. I'm about to post v2 (but haven't yet!), I can reply here with the link once v2 is posted. [1] https://pastebin.com/Nj8ixpkX [2] https://yhbt.net/lore/all/20221013163551.6775-1-palmer@rivosinc.com/ Evan Green (2): riscv: Add Linux hwprobe syscall support riscv: Add and use alignment-ignorant memcpy sysdeps/riscv/memcopy.h | 28 +++++ sysdeps/riscv/memcpy.c | 65 +++++++++++ sysdeps/riscv/memcpy_noalignment.S | 103 ++++++++++++++++++ sysdeps/unix/sysv/linux/riscv/Makefile | 8 +- sysdeps/unix/sysv/linux/riscv/Versions | 3 + sysdeps/unix/sysv/linux/riscv/hwprobe.c | 30 +++++ .../unix/sysv/linux/riscv/memcpy-generic.c | 24 ++++ .../unix/sysv/linux/riscv/rv32/arch-syscall.h | 1 + .../unix/sysv/linux/riscv/rv32/libc.abilist | 1 + .../unix/sysv/linux/riscv/rv64/arch-syscall.h | 1 + .../unix/sysv/linux/riscv/rv64/libc.abilist | 1 + sysdeps/unix/sysv/linux/riscv/sys/hwprobe.h | 34 ++++++ sysdeps/unix/sysv/linux/syscall-names.list | 1 + 13 files changed, 298 insertions(+), 2 deletions(-) create mode 100644 sysdeps/riscv/memcopy.h create mode 100644 sysdeps/riscv/memcpy.c create mode 100644 sysdeps/riscv/memcpy_noalignment.S create mode 100644 sysdeps/unix/sysv/linux/riscv/hwprobe.c create mode 100644 sysdeps/unix/sysv/linux/riscv/memcpy-generic.c create mode 100644 sysdeps/unix/sysv/linux/riscv/sys/hwprobe.h
Comments
On 2/6/23 09:48, Evan Green wrote: > > This series illustrates the use of a proposed Linux syscall that > enumerates architectural information about the RISC-V cores the system > is running on. In this series we expose a small wrapper function around > the syscall. An ifunc selector for memcpy queries it to see if unaligned > access is "fast" on this hardware. If it is, it selects a newly provided > implementation of memcpy that doesn't work hard at aligning the src and > destination buffers. > > This is somewhat of a proof of concept for the syscall itself, but I do > find that in my goofy memcpy test [1], the unaligned memcpy performed at > least as well as the generic C version. This is however on Qemu on an M1 > mac, so not a test of any real hardware (more a smoke test that the > implementation isn't silly). > > v1 of the Linux series can be found at [2]. I'm about to post v2 (but > haven't yet!), I can reply here with the link once v2 is posted. > > [1] https://pastebin.com/Nj8ixpkX > [2] https://yhbt.net/lore/all/20221013163551.6775-1-palmer@rivosinc.com/ Re the syscall: I question whether the heterogenous cpu case is something that you really want to query. In order to handle migration between such cpus, any such query must return the minimum level of support. Remove that possibility, and this becomes a simple array reference. Now you need to decide whether a vdso call, or HWCAP2 as pointer to read-only data is more or less efficient or extensible. r~
On 06/02/23 18:28, Richard Henderson via Libc-alpha wrote: > On 2/6/23 09:48, Evan Green wrote: >> >> This series illustrates the use of a proposed Linux syscall that >> enumerates architectural information about the RISC-V cores the system >> is running on. In this series we expose a small wrapper function around >> the syscall. An ifunc selector for memcpy queries it to see if unaligned >> access is "fast" on this hardware. If it is, it selects a newly provided >> implementation of memcpy that doesn't work hard at aligning the src and >> destination buffers. >> >> This is somewhat of a proof of concept for the syscall itself, but I do >> find that in my goofy memcpy test [1], the unaligned memcpy performed at >> least as well as the generic C version. This is however on Qemu on an M1 >> mac, so not a test of any real hardware (more a smoke test that the >> implementation isn't silly). >> >> v1 of the Linux series can be found at [2]. I'm about to post v2 (but >> haven't yet!), I can reply here with the link once v2 is posted. >> >> [1] https://pastebin.com/Nj8ixpkX >> [2] https://yhbt.net/lore/all/20221013163551.6775-1-palmer@rivosinc.com/ > > Re the syscall: > > I question whether the heterogenous cpu case is something that you really want to query. In order to handle migration between such cpus, any such query must return the minimum level of support. > > Remove that possibility, and this becomes a simple array reference. Now you need to decide whether a vdso call, or HWCAP2 as pointer to read-only data is more or less efficient or extensible. It should at least work if kernel trap/emulate unaligned or any instruction not supported by the other code, although it would be really subpar. I would expect that kernel would report the minimum ISA as well. I would recommend also to cache the values as we do for aarch64/x86/powerpc to avoid issue multiple syscall on symbol resolution (check cpu-features.c).