From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) by sourceware.org (Postfix) with ESMTPS id E1B3E386C589 for ; Thu, 15 Feb 2024 16:50:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E1B3E386C589 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E1B3E386C589 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::435 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708015833; cv=none; b=Zt2BqLlz1mu17PPYNJwSE2INmtKhVLbUrEA+KA7lPQ/JFaDxSLyZujViz7kiP0ir6uYwPJikPhK+5N1c2MBNIGFXjiSyRnMFxQ1VtWPL//yqBT1kXqq4jJ/jz9s9dZCHn05buVCKfJIVTiY/VfxqgIHpwXMT4kgEx84JZ+5WWME= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708015833; c=relaxed/simple; bh=ptszu+7RhRfetfSIKtMTaBIdQKfcpptdGFp47I2gdIo=; h=DKIM-Signature:Date:Subject:From:To:Message-ID:Mime-Version; b=mZLR82+ZzbbyeVv9aGfKLWmvOSuIhCHAuQzm220RMEBqICGc4fwUDXp8GNf6WDmcv7QZOeQ1s73GdCSWqaKqdvqEFqtpBXev4Fi69/vUMF9zmF7dqaEg3m6jGl4iEphQK+e7zPxBDFiShnq2idrma1n61KbTdB1aPaZesQMx0kA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pf1-x435.google.com with SMTP id d2e1a72fcca58-6e0cc8d740cso908586b3a.3 for ; Thu, 15 Feb 2024 08:50:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1708015825; x=1708620625; darn=sourceware.org; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=s6jJrm8BNrvFuPPOiqehJp6R1zkJWnuxlTCPxLGa3CE=; b=JKCuMxK/YO4dQYqAoprmi4UpyC13npIZmynv07IGRrSZfTL37HQWphuJ3LD3bjKlb5 BQrUdQaHTfrCPLUNLJGGeR+wIiERl5xB1Bpe0W+jtKt75DGHwIqRv3EiytfetVdjjgXL 77+MB2p9xnHxFccHHUSuLUep3u7DODr599MxWKPZ2/3zdEbzGyVAbfVjr7+IjemmD+5O PZbCYjD82Mt7SVogfBjlEkGtY1zkVpFcgGbaCd2NZMvHqjp/zurfIPEjKj8pxffTVgKZ n+s69DG6NhE0ImzulKG2A214UT/BWYb5dwjZyiPI6uy2zN9LssHWJvBEf2ce623RBeJz ddgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708015825; x=1708620625; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=s6jJrm8BNrvFuPPOiqehJp6R1zkJWnuxlTCPxLGa3CE=; b=QO17BUva3P97BJ0GV5aZ3tlHTmCnaeItnib2rRIFOknjRpqpA1UXLIH4mhtHO7JhJv PFwzr/IZpZGB0Tnzn1CT8S5PWhrK3699KscExCgVOcn8FhAbjyyToMipZGi+z2SEYyTd NAk3i5vyxwRd62WzABhiE+w5DJOg3areIYHzakEwWN3R2CC1WMCx1Dx5DOUAD2X1djbx uapMrvbQImhAn/HYqy9yOmbr5oWm8r2PuZYlZpZ6retdn3iqtF/NhPPGI/l5t9Jgtuc8 408D4hhG/jaO0II6oj4vt/bPfXvPYGyvg8qZ5b0O/LZ4jprPE1N+TNWaA8ALZzAoZBr7 FG4Q== X-Forwarded-Encrypted: i=1; AJvYcCVI671sYYIgOfQW6taOANx/PiHCPyN2LxDcduS28A6zfezGclSbes1w52sIo85diAKAfG5kIhwTb4C37MoBhGOWZtHWb8tW4ch1 X-Gm-Message-State: AOJu0YxwwqWnj8dFDGk3KGiTAly6H5r+CdIFzZLOmyEiRB5MmDyn2iDv D4i08gQkeuWbcpQ1aPc2uY8ZZjcNqDvEBuS/pzGnQ6jIGiSMPUHvqeVaBKL/S3o= X-Google-Smtp-Source: AGHT+IHKGlppvbLZJLJgOCPtrBBczUkfMn/BnDw2y7wRhxOGIA9KMvndvQD891hCu/WTclJE1NHWeQ== X-Received: by 2002:a05:6a00:6814:b0:6e0:8128:5ca6 with SMTP id hq20-20020a056a00681400b006e081285ca6mr2321276pfb.2.1708015824826; Thu, 15 Feb 2024 08:50:24 -0800 (PST) Received: from localhost ([192.184.165.199]) by smtp.gmail.com with ESMTPSA id u15-20020a056a00098f00b006e129d5d720sm1118157pfg.158.2024.02.15.08.50.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Feb 2024 08:50:24 -0800 (PST) Date: Thu, 15 Feb 2024 08:50:24 -0800 (PST) X-Google-Original-Date: Thu, 15 Feb 2024 08:49:19 PST (-0800) Subject: Re: [PATCH v12 0/7] RISC-V: ifunced memcpy using new kernel hwprobe interface In-Reply-To: CC: adhemerval.zanella@linaro.org, libc-alpha@sourceware.org, Vineet Gupta , fweimer@redhat.com, slewis@rivosinc.com, jrtc27@debian.org From: Palmer Dabbelt To: Evan Green Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 Thu, 15 Feb 2024 07:48:03 PST (-0800), Evan Green wrote: > On Wed, Feb 14, 2024 at 10:16 AM Adhemerval Zanella Netto > wrote: >> >> >> >> On 14/02/24 11:31, Evan Green wrote: >> > >> > This series illustrates the use of a recently accepted 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. >> > >> > For applications and libraries outside of glibc that want to use >> > __riscv_hwprobe() in ifunc selectors, this series also sends a pointer >> > to the riscv_hwprobe() function in as the second argument to ifunc >> > selectors. A new inline convenience function can help application and >> > library callers to check for validity and quickly probe a single key. >> >> I still think we should address Jessica Clarke remarks for the ifunc ABI [1]. >> I recall that Florian has tried to address the ifunc ordering and that >> Jessica proposed solutions was not fully sufficient to address all the >> ifunc corner cases. >> >> [1] https://sourceware.org/pipermail/libc-alpha/2024-January/154082.html > > I haven't invested the time yet in studying the resolver to understand > how feasible Jessica's suggestion is. I was sort of hoping Florian > would chime in with an "oh yeah let's do that" or "no, it doesn't > work". I suppose I still am :) The discussion's over here: https://inbox.sourceware.org/libc-alpha/20231017044641.pw2ccr6exvhtmhkk@google.com/ I was inclined to just ignore it: Florian explained what's going on with the multiple libraries constraint, so we're kind of just going around in circles at that point. I'm also not sure the argument makes a whole lot of sense in the first place. The core of the argument seems to be around binary compatibility with other kernels/libcs, but there's a ton of reasons why binaries aren't compatible between those systems. So if glibc just has a more complex IFUNC resolving scheme and that ends up requiring the extra agrument, then users of glibc have to go deal with that -- other systems/libcs might make different decisions, but that's just how these things go. Looks like Maskray is proposing making glibc's IFUNC resolving. That's a generic glibc decision and I don't really understand this stuff well enough to have much of an opinion -- sure maybe the multi-library IFUNC resolving is overkill, but aside from doing some similar grep of all the sources (or trying some builds and such) I'm not sure how to tell if we're safe breaking the ABI there. That said, we're not comitting to ABI stability until the release. So if we decide to make a generic glibc change we can always go drop the argument, that should be easy. Maybe we even just throw out a RFC patch to do it, unless I'm missing something the code is the easy part here (we're essentially just going back to one of the early versions, from before we knew about this resolving order complexity). > Alternatively, patches 1-3 of this series stand on their own. If the > ifunc aspect of this is gated on me doing a bunch of research, it > might at least make sense to land the first half now, to get Linux > users easy access to the __riscv_hwprobe() syscall and vDSO. I'm OK with that, too. > > -Evan