From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) by sourceware.org (Postfix) with ESMTPS id 26C343858D3C for ; Wed, 29 Mar 2023 19:16:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 26C343858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oi1-x22f.google.com with SMTP id r84so11134318oih.11 for ; Wed, 29 Mar 2023 12:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1680117403; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=OGBM98mJ9q3gZXbV+FiSR5IWXcZLXc3Wa5J0bST2P4c=; b=vYKZ7PdmLSWmzt00EEBU3RF77laXC1VUv11p5xwq4FY5rGEuPkO/q9JEm7lH1IWUYE v0oSo0kfAcK9N3DLaWon1nRn+BKRIdWlgE1nTFPNiO0R6zrvSPgEVbVsbRhSfC8fedPk ZBhgh+ezGfPF2/UvD8IRf8Ls0T25oe3/gufxJQB9MWflTrW2CI7GkEDNKEAlb5qrp2E+ K1RaXGTYrwKCXVNjPaKeO/Wl13FR9W9+a4DSmPKfNFLq7kZEpJY/kv0hJwVbkSam27tu 9Gp3FWGZC+j2yP+Qq3ogB+59jwYZTXBt/5A2edgpXvILb8JFzq4ufy69ZQxIYJb5Xpl3 /ZXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680117403; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OGBM98mJ9q3gZXbV+FiSR5IWXcZLXc3Wa5J0bST2P4c=; b=guLERz1LETqxc4xmY10rVRzXgwZGYdvdlkeAZd/UWT/rJsAofY4TZXfwLRUxwOSjKS a2eAVEUHvBxm8hoda1hDTzrlGVBGuBHlimgmxTbrziLQ8cXXE29IWSkWFoHo77j3zSHo I53ofJDp79PfRUr7PABrIiB/suPhG4oYeJHn4UqEmADlABFtf1prfgBc1n+wTt6ZOt5O EuJlY3QGXg3KK40JyAIkGLf0laClKcGmahBhxQvk3XxA94syB0laFyXRHI08tY97mmNW 4mE7zuiTsCrcfeJ8bvOf0eJNUcoRCJ/siVAtzlJv3eAJkUurhnX0tev1J+xZUzJVqbHI K5vw== X-Gm-Message-State: AAQBX9fjqKtrhiOJbqPeu/6ZCwWkT6ZQdgwlKSrGgHASGqqYLL6YrlVD o+Q64Vs63vHfRHNI+19Sg9o7RA== X-Google-Smtp-Source: AKy350aulXuRWAjwKFFijiZLAElP/U25JVCUqYkFKxKWCH1xXM/9STUqi1Q1tCs7t88jSL9JIkH+OA== X-Received: by 2002:a05:6808:181d:b0:389:4bee:a523 with SMTP id bh29-20020a056808181d00b003894beea523mr4767182oib.36.1680117403380; Wed, 29 Mar 2023 12:16:43 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c1:60f9:1426:1d2d:d6b:1761? ([2804:1b3:a7c1:60f9:1426:1d2d:d6b:1761]) by smtp.gmail.com with ESMTPSA id c3-20020aca1c03000000b0038901ece6e9sm4864991oic.12.2023.03.29.12.16.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Mar 2023 12:16:42 -0700 (PDT) Message-ID: Date: Wed, 29 Mar 2023 16:16:39 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH v2 0/3] RISC-V: ifunced memcpy using new kernel hwprobe interface Content-Language: en-US To: Palmer Dabbelt Cc: Evan Green , libc-alpha@sourceware.org, slewis@rivosinc.com, Vineet Gupta References: From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,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 List-Id: On 28/03/23 21:01, Palmer Dabbelt wrote: > On Tue, 28 Mar 2023 16:41:10 PDT (-0700), adhemerval.zanella@linaro.org wrote: >> >> >> On 28/03/23 19:54, Palmer Dabbelt wrote: >>> On Tue, 21 Feb 2023 11:15:34 PST (-0800), 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). >>> >>> QEMU isn't a good enough benchmark to justify a new memcpy routine in glibc.  Evan has a D1, which does support misaligned access and runs some simple benchmarks faster.  There's also been some minor changes to the Linux side of things that warrant a v3 anyway, so he'll just post some benchmarks on HW along with that. >>> >>> Aside from those comments, >>> >>> Reviewed-by: Palmer Dabbelt >>> >>> There's a lot more stuff to probe for, but I think we've got enough of a proof of concept for the hwprobe stuff that we can move forward with the core interface bits in Linux/glibc and then unleash the chaos... >>> >>> Unless anyone else has comments? >> >> Until riscv_hwprobe is not on Linus tree as official Linux ABI this patchset >> can not be installed.  We failed to enforce it on some occasion (like Intel >> CET) and it turned out a complete mess after some years... > > Sorry if that wasn't clear, I was asking if there were any more comments from the glibc side of things before merging the Linux code. Right, so is this already settle to be the de-factor ABI to query for system information in RISCV? Or is it still being discussed? Is it in a next branch already, and/or have been tested with a patch glibc? In any case I added some minimal comments. With the vDSO approach I think there is no need to cache the result at startup, as aarch64 and x86 does.