From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by sourceware.org (Postfix) with ESMTPS id 4E3D23858CDB for ; Thu, 30 Mar 2023 18:32:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4E3D23858CDB 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-lf1-x135.google.com with SMTP id c29so25736315lfv.3 for ; Thu, 30 Mar 2023 11:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; t=1680201152; 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=M1sIhEH8+msYXIeoTenO2jWmwRGGhHhkBx9bBlpc4OI=; b=PKyS3GI1gO4cLEtI4YJkOHqE/Ao2L2efxA8yUW9F9nneaoFJde6OoxDQGBdDy2yxoz 1wsPS2Bsi8CH+3fLjJAMJqWmA1gb3sOi/8CeHuWyO3GndyS5y8yY1x/TG+hgnCHlEU/j OL8KXQP1eAfgXoyPtlsBfYQPlimuyBzRS3x8hEOeNl2SKAcICaiSTH/Nvf0YR9vJQB2q zuAkmSPS1XUme5mWnhB9zU9CvbDtezB/Vtppvy+QW0moxAx95Jt+MI5Gv3xmi5tpAsRf JckWsHlm5JV17HrMIVTh7AoE3dkQ0ylJq7373xJ8RA7qf2RcUDoop8Dq0Vzamy3UtRU9 lczQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680201152; 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=M1sIhEH8+msYXIeoTenO2jWmwRGGhHhkBx9bBlpc4OI=; b=z345WVCVA8iaIEORVs/mYifWG+VlrqqOhoYinAu9DXzOBdHW2qqqeihxMnkaI3TOyQ pc+G+z1fP8kGpPep9lqFhn+vFP9om/kIsAE1TEnMl3c/lz+Gvox+v4kttWqnygnZgAdp Dic+N1qrvIXey+Z0YYTPWJAM9WPKO7kRiVlMyanRjhEYbXWB+f1HwENDIItNY9rpzKu3 DqtQiBWmeNhrqqK8UYfazOpxvSlV6f3297S0kJPPHnTUJMFVbx1iQm85Cty3q820a0dP KcsQ+bM/Ky+6c77O0Z8BXxnU3YOO5FKGt2bY2UvauHeX3RI4rvRwNbM4ku/TPWvONNCY DYYA== X-Gm-Message-State: AAQBX9cbVUQ+AB95VkD96pa6+xygo/dIuB6NgCjXGAbwdUiiPtaOWsjr 7Ccm/iV/ErvulTXqPAiA5RuTmmAkvnQTBK0OlIcuWQ== X-Google-Smtp-Source: AKy350aJUNnQdpmuu3P6GzBmoEx3Q68pnDQZL8jeS3LKALM60ys8Bl7GvsjL1j8Mnne7Cebc5gjUi780YwVkBbJmEno= X-Received: by 2002:a19:a401:0:b0:4d8:1c0e:bfc7 with SMTP id q1-20020a19a401000000b004d81c0ebfc7mr7050173lfc.13.1680201151804; Thu, 30 Mar 2023 11:32:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Evan Green Date: Thu, 30 Mar 2023 11:31:56 -0700 Message-ID: Subject: Re: [PATCH v2 0/3] RISC-V: ifunced memcpy using new kernel hwprobe interface To: Adhemerval Zanella Netto Cc: Palmer Dabbelt , libc-alpha@sourceware.org, slewis@rivosinc.com, Vineet Gupta , Arnd Bergmann Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,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: Hi Adhemerval, On Wed, Mar 29, 2023 at 1:13=E2=80=AFPM Adhemerval Zanella Netto wrote: > > > > On 29/03/23 16:45, Palmer Dabbelt wrote: > > On Wed, 29 Mar 2023 12:16:39 PDT (-0700), adhemerval.zanella@linaro.org= wrote: > >> > >> > >> On 28/03/23 21:01, Palmer Dabbelt wrote: > >>> On Tue, 28 Mar 2023 16:41:10 PDT (-0700), adhemerval.zanella@linaro.o= rg 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 sy= stem > >>>>>> is running on. In this series we expose a small wrapper function a= round > >>>>>> the syscall. An ifunc selector for memcpy queries it to see if una= ligned > >>>>>> access is "fast" on this hardware. If it is, it selects a newly pr= ovided > >>>>>> implementation of memcpy that doesn't work hard at aligning the sr= c 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 perfor= med 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 th= e > >>>>>> 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 som= e simple benchmarks faster. There's also been some minor changes to the Li= nux side of things that warrant a v3 anyway, so he'll just post some benchm= arks 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 (lik= e 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 comme= nts 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? > > > > It's not in for-next yet, but various patch sets / proposals have been = on the lists for a few months and it seems like discussion on the kernel si= de has pretty much died down. That's why I was pinging the glibc side of t= hings, if anyone here has comments on the interface then it's time to chime= in. If there's no comments then we're likely to end up with this in the n= ext release (so queue into for-next soon, Linus' master in a month or so). > > > > IIUC Evan's been testing the kernel+glibc stuff on QEMU, but he should = be able to ack that explicitly (it's a little vague in the cover letter). = There's also a glibc-independent kselftest as part of the kernel patch set:= https://lore.kernel.org/all/20230327163203.2918455-6-evan@rivosinc.com/ . > > I am not sure if this is latest thread, but it seems that from cover lett= er link > Arnd has raised some concerns about the interface [1] that has not been f= ully > addressed. I've replied to that thread. > > From libc perspective, the need to specify the query key on riscv_hwprobe= should > not be a problem (libc must know what tohandle, unknown tags are no use) = and it > simplifies the buffer management (so there is no need to query for unknow= n set of > keys of a allocate a large buffer to handle multiple non-required pairs). > > However, I agree with Arnd that there should be no need to optimize for h= ardware > that has an asymmetric set of features and, at least for glibc usage and = most > runtime feature selection, it does not make sense to query per-cpu inform= ation > (unless you some very specific programming, like pine the process to spec= ific > cores and enable core-specific code). I pushed back on that in my reply upstream, feel free to jump in there. I think you're right that glibc probably wouldn't ever use the cpuset aspect of the interface, but the gist of my reply upstream is that more specialized apps may. > > I also wonder how hotplug or cpusets would play with the vDSO support, an= d how > kernel would synchronize the update, if any, to the prive vDSO data. The good news is that the cached data in the vDSO is not ABI, it's hidden behind the vDSO function. So as things like hotplug start evolving and interacting with the vDSO cache data, we can update what data we cache and when we fall back to the syscall. -Evan > > [1] https://lore.kernel.org/lkml/20230221190858.3159617-1-evan@rivosinc.c= om/T/#m452cffd9f60684e9d6d6dccf595f33ecfbc99be2