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 23EB6386C5B4 for ; Thu, 15 Feb 2024 18:45:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 23EB6386C5B4 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=google.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 23EB6386C5B4 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::f29 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708022725; cv=none; b=rJGg6E7HdfaQ8V4Th8RxKtJS0g6ocjJbm/gbe/rQoggc8LktX37XzBz1LaMpUOveA58QsjuZ3jyA3UOQiXi+7IjFErtSlWLbHLctsuCVOseD04XxQZgfLyS5QWTztIteYZW0LqqLUFYiBwX93HuAsogrjWwNbR0fnPOAlYoDy2Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708022725; c=relaxed/simple; bh=RmE0BrlVBFtR5kHQdvMVCB1Tx2a/F6meo4+U6oGsSog=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=a7B0IwScvdcyq9i8gTBdxxaTuiH3ptRjtkroQohmKpL4kQtU0bKcBX19Pga+e3mKf41yUcpw7TLWJZJKSsZ0o9vPnC+PoN8lWMFcRPk7uMzVT8S7dkXdD8MQ9IoMaEEoE3WVcHN9tKY8XUNXlU7FCH6pxmvs/6/f0QmOQy6iGlM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-qv1-xf29.google.com with SMTP id 6a1803df08f44-68f2a6fdeffso2652196d6.1 for ; Thu, 15 Feb 2024 10:45:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1708022722; x=1708627522; darn=sourceware.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=X4P68Z4WU4FfIVobyJSJAJmVAWAA/dYMJEDQ0ePhKmY=; b=svmO3UN7F9G6YSKWNEGheDOhV7oXGyVlo145zofUz6PsqX5T919SlM3gQ7C1l9L07e pBFjflVAR7qXeow0Hxa3XoEQsUyyUStLGv8iWDeWER/J9+uhnuGR4YmydPgph36gLKLu pB3uvphEH4YYZcZsSlfou29qFXSeC2FYfIghWayhf1IS48HaWD3aoPC90brAF2YI72bm 7yFdioZvlDw5GHZjZyPqF0/ck1ex24HKpElzRIRcWYj4TCOjXqW0BNZQect0Y420XHQj Odtal51lOv/i3nfMYQpmn+1zl0GygfRL1TRZ9Fhma7V+AZWLHnq+Hf6rJRudcxHV/JH/ nUrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708022722; x=1708627522; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=X4P68Z4WU4FfIVobyJSJAJmVAWAA/dYMJEDQ0ePhKmY=; b=K6v9RDhxnRiejufTvtPuKEkbhyzPLhBslpIs5jLJzYEmrOkAUwuRq6rZi7ZpN6gCkK xkHcOkBGlpZ01J5TowCh/etEe56EhbQaEJA0vlBUItI9PeW3nRldVzsCFhKXbjyBykvx jql4QLuWdZ+p186tTt5bllFJsJ6h42KcG5bWRBSdcnKd+rctrF0ItTup6ruChdRae5lH hSzSV7Tyx4M74LQEVXTYzTjToI9zSyiwfpgEKrMiRUOylkEtJhpmJZE2I/Ie5yQYR3w7 pxVS4vH1mjQsFfe+yxlFDYvnGgm4fcw43IU+p+Ec5FJeGckXTY2B3vpJAGHmzhdD2JFl yXnA== X-Forwarded-Encrypted: i=1; AJvYcCWew59f5orFlZjRPwxMLafq+BFv17xtj4GL0u3RXxD9WVyJ/zt64W0Ug/qHTGgwjNhLPdg2E4ZWv2vuGk5mLyhtpm1Rc4zBRx+i X-Gm-Message-State: AOJu0YzSGYegPmhx8lkBfF2/9+vosy2dNIqnLDJuG2U9q6bvw477AcZP atdzldlnLhpLpWWelTOgBHwAsMxhKi6VeH4w1dOFjhnJt3D7uRbqyOO+ulrglf2yHKzU6pzywyu /1IH+R7mnOJ0HoCuGYo1LD9tQop+N58eC2ErB X-Google-Smtp-Source: AGHT+IHcrJXcW5/1TqQmAOrflxJn+xbRQSXGnC6/gM+bzfFVNvTxKr2UpE4IkS05hOlPS9sgZsIo1eWJqwpgkUpU2Sk= X-Received: by 2002:a0c:da03:0:b0:68f:2b1d:42b2 with SMTP id x3-20020a0cda03000000b0068f2b1d42b2mr1314925qvj.34.1708022722224; Thu, 15 Feb 2024 10:45:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: enh Date: Thu, 15 Feb 2024 10:45:10 -0800 Message-ID: Subject: Re: [PATCH v12 0/7] RISC-V: ifunced memcpy using new kernel hwprobe interface To: Palmer Dabbelt Cc: Evan Green , adhemerval.zanella@linaro.org, libc-alpha@sourceware.org, Vineet Gupta , fweimer@redhat.com, slewis@rivosinc.com, jrtc27@debian.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-17.8 required=5.0 tests=BAYES_00,DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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, Feb 15, 2024 at 9:22=E2=80=AFAM Palmer Dabbelt wrote: > > On Thu, 15 Feb 2024 09:00:03 PST (-0800), enh@google.com wrote: > > On Thu, Feb 15, 2024 at 8:50=E2=80=AFAM Palmer Dabbelt wrote: > >> > >> On Thu, 15 Feb 2024 07:48:03 PST (-0800), Evan Green wrote: > >> > On Wed, Feb 14, 2024 at 10:16=E2=80=AFAM Adhemerval Zanella Netto > >> > wrote: > >> >> > >> >> > >> >> > >> >> On 14/02/24 11:31, Evan Green wrote: > >> >> > > >> >> > This series illustrates the use of a recently accepted Linux sysc= all that > >> >> > enumerates architectural information about the RISC-V cores the s= ystem > >> >> > 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 un= aligned > >> >> > access is "fast" on this hardware. If it is, it selects a newly p= rovided > >> >> > implementation of memcpy that doesn't work hard at aligning the s= rc and > >> >> > destination buffers. > >> >> > > >> >> > For applications and libraries outside of glibc that want to use > >> >> > __riscv_hwprobe() in ifunc selectors, this series also sends a po= inter > >> >> > to the riscv_hwprobe() function in as the second argument to ifun= c > >> >> > 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 ifun= c ABI [1]. > >> >> I recall that Florian has tried to address the ifunc ordering and t= hat > >> >> 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 understa= nd > >> > 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.pw2ccr6exvhtmhk= k@google.com/ > >> > >> I was inclined to just ignore it: Florian explained what's going on wi= th > >> 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 compatibili= ty > >> 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 thes= e > >> things go. > > > > yeah, i struggle with the portability premise too. not least because > > macOS/iOS (which is obviously the most common "other platform" for me > > with my Android hat on) doesn't have ifuncs at all. that's quite a big > > blocker to any dream of portability. > > > > as i've said before, in a survey of all the open source libraries that > > go into Android, there are none that don't support macOS/iOS, and so > > there are none that actually rely on ifuncs. ifunc usage is limited to > > libc (which is why we libc maintainers get bikeshedded by stuff like > > this) and compiler-generated FMV stuff. i'd argue that "real people" > > (app developers) should probably be looking at the latter anyway, and > > it's our job to make that work (which happens once^Wtwice, in llvm and > > gcc). > > > > also, the fact that Android is doing what's proposed here (with the > > extra argument) means there'd be _some_ incompatibility even if glibc > > and FreeBSD didn't do that. > > So you're already committed to that ABI? "pretty much" given glibc release cycles and Android release cycles... the current API addresses a real problem with current dynamic linkers, and -- though it would have been great to make a different decision 16 years ago -- between the already stated reasons and the potential for app compat issues (and a distaste for having the riscv64 linker behavior differ from the already-shipped architectures), i think we'll want something like that... > > (Android's only source incompatibility with glibc at the moment is the > > lack of the single-probe helper inline, which i fear will encourage > > _worse_ code, but suspect will actually be unused in practice anyway > > for the same "ifuncs are 'assembler' for libc/toolchain, and > > library/app developers doing stuff themselves will continue to use > > regular function pointers like they do today" reasons.) > > > >> 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 IFUN= C > >> resolving is overkill, but aside from doing some similar grep of all t= he > >> 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 pat= ch > >> 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