From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) by sourceware.org (Postfix) with ESMTPS id 97F583858D33 for ; Tue, 7 Feb 2023 12:50:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 97F583858D33 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-ot1-x329.google.com with SMTP id p24-20020a056830131800b0068d4b30536aso4130412otq.9 for ; Tue, 07 Feb 2023 04:50:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=0nQxI4KoJcb8wIaUrCvfRTjZb1NO1lmnQqEodBYxSqc=; b=W7y+d0D8//YgUgcCgLCqMdqQH+/7CE0ru7MOHIR65cT317hhYQ9Q3CDlUtw0lD1/Af 1LvVaMydvtUdREfXzRriww9/uFyyF/VeGpDjjVxUla95rpB7+UOikfutpOTqnPA/DNZS 2vpp2VzqqLRAu5DZ7WvNPSNNjQ6/s7FXHFWNV5AdcXIqqRHB5oaiI+MoYk7O8mx6jugw 1psuJ/AIf53Mw1N1Tspq5Y/wZVtI5YzYPTxyktL8oJsze2/Gg2RmTEJa37M58BezPt5J br/8nJGkW283zc2KSEFJv2KEH19oqS7lUlLUR2MeFERcG0KymfYUm+ZKeUjcb2p1fxu3 r9Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :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=0nQxI4KoJcb8wIaUrCvfRTjZb1NO1lmnQqEodBYxSqc=; b=1wPe7EMO05zTG313nWsMDROJSJce8kkcY4G0YhqsKC12/SkDZXA5jkyQsY5f6KKIme xmFMZbhAxzEJtqDCTSwlA1APwH6D5kiyZs3TSaXgqIchyboATmnj4RvUdC+MIrnwn+yE 2DiCSyUROVqv/ROMRjItTbl8uKapa96Y1r1knDUAcGuifnoIsE1g+TpoayM7JJyColfm fzl+T9Rgq76n3OZfyGXcloPm4+hZRnyZQB4US4REINSKIuHCQHDxdeNCGkdPq555TuMB SyQNZpuYtIYzPFAQ/L7DUpjwtwaUokcskR3LuvFzH1ivRPlhfxZhEk/N9ENoRem1xwLT bshw== X-Gm-Message-State: AO0yUKWWhuO6ytk68xx+smsBob290yV92uXeNWGWOAP8TV8OjhVpbRTJ KyToKx+Z3iQSr0pVptrIsNLY15mfbP06NbZCikE= X-Google-Smtp-Source: AK7set+CynmnF2cViL9YWGcUd9cmm1jingVaDg5s4CvEotlmiM27vxxOfbGGR0oC+q0svxKZRwyuVw== X-Received: by 2002:a9d:311:0:b0:684:e812:caf with SMTP id 17-20020a9d0311000000b00684e8120cafmr1727165otv.13.1675774202069; Tue, 07 Feb 2023 04:50:02 -0800 (PST) Received: from ?IPV6:2804:1b3:a7c2:8ced:8458:e6b7:cf66:aa19? ([2804:1b3:a7c2:8ced:8458:e6b7:cf66:aa19]) by smtp.gmail.com with ESMTPSA id r184-20020aca44c1000000b003786e78f2b5sm5538633oia.9.2023.02.07.04.50.00 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Feb 2023 04:50:01 -0800 (PST) Message-ID: <6980f749-8f38-fb03-d4b8-d9006635fa83@linaro.org> Date: Tue, 7 Feb 2023 09:49:59 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH 0/2] RISC-V: ifunced memcpy using new kernel hwprobe interface Content-Language: en-US To: libc-alpha@sourceware.org References: <20230206194819.1679472-1-evan@rivosinc.com> <878ce324-c4d7-5fc5-b964-d59220f724d2@linaro.org> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <878ce324-c4d7-5fc5-b964-d59220f724d2@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,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 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).