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 F0D423858C53 for ; Thu, 30 Mar 2023 19:38:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F0D423858C53 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 b19so15046059oib.7 for ; Thu, 30 Mar 2023 12:38:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1680205095; 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=vYMT++xuv4n27ESrPzvv2JO6IoQcCS+VGxJDPeJvjmg=; b=GBT5DhXKQhhtXWUREIpECYHvf0Mcmg4Zfjyigu67Bwlx8COCqpN+C4c8Bd2Q5rzJL2 9/jhUQvEdEtKu6hR0F7R4p7adyjmnmJ0ToVcj+iVEV5GJittRwr3mOL7FQSZHxh8an0d 5b3R2HePR2HpIHWbHDRlaD0kHyjIARLmDndgXlhRQVJ6Bw94knJVyeCtQAo8xsWSWJKu wAx6par8S0PxD1sLbBjmL3l3zBGvh0yuFtvH5NcR7JcaK5/tBkuRHMvajraP5Ezobbk9 tWU8jz+HsfscsAzUC300d0a1twpw16W7wXMlsy56QDrw2nuVg30zpRm0Ks6SgLKibdq6 r6zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680205095; 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=vYMT++xuv4n27ESrPzvv2JO6IoQcCS+VGxJDPeJvjmg=; b=sQxM6G42L4OVFrVHP6Gz2xFOc75NhnsicQ3q3OqWUgnhy8eoWCDzEv8gSRQEQA0ZSp 3LKXN+VKlCIVBmolXhFENWDfrRUQ3VKRU+vNX/gnZBUR5Dm8/IT9eF5yLbqJZgYFihEf hK9QVWjmuAHy/s49Ushfk5e9aEPKcOUC3d/V89+2Qn2NXKz8+pwXJ+d3m8FEH5C8Xn1g eKyBzJpd5TGgswkYiNFGEgrr1r+PQTg8Had2Zro36iQc0RLqUp2KV+njd5YKtslcV2j6 9JfSxe7eIoYV192qVgoX+DvYCbMXo+CuNmu9Q4JuFvKdmw6gQaHbPAjI24Xe2OHadxzp BB8A== X-Gm-Message-State: AO0yUKVR/kY0GhEo1pBCLqQgFF53E13W4/pHyLBGdKJCKeG+wGf31oa3 yZMsPLRbFBXrT1OgNF6tArRewA== X-Google-Smtp-Source: AK7set92mR1q5X1253NxWWtX2shKj+iD04I4RQtK8VNvQ09bpLCVFpZceKBcs8nafz8knGFxUDCuYA== X-Received: by 2002:a05:6808:359:b0:386:bbe6:f9a5 with SMTP id j25-20020a056808035900b00386bbe6f9a5mr10803082oie.1.1680205093778; Thu, 30 Mar 2023 12:38:13 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c1:60f9:4ca7:df5c:ca4c:27b4? ([2804:1b3:a7c1:60f9:4ca7:df5c:ca4c:27b4]) by smtp.gmail.com with ESMTPSA id j10-20020aca170a000000b00389509965e3sm196876oii.58.2023.03.30.12.38.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Mar 2023 12:38:13 -0700 (PDT) Message-ID: <0fe9357f-b960-065c-a3a7-8abfbbd5017c@linaro.org> Date: Thu, 30 Mar 2023 16:38:09 -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: Jeff Law , Palmer Dabbelt Cc: Evan Green , libc-alpha@sourceware.org, slewis@rivosinc.com, Vineet Gupta References: <9290df69-8946-3b67-63ea-3d386a3c30a6@gmail.com> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <9290df69-8946-3b67-63ea-3d386a3c30a6@gmail.com> 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,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 30/03/23 03:20, Jeff Law wrote: > > > On 3/29/23 13:45, Palmer Dabbelt wrote: > >> 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 side has pretty much died down.  That's why I was pinging the glibc side of things, 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 next release (so queue into for-next soon, Linus' master in a month or so). > Right.  And I've suggested that we at least try to settle on the various mem* and str* implementations independently of the kernel->glibc interface question. > > I don't much care how we break down the problem of selecting implementations, just that we get started.   That can and probably should be happening in parallel with the kernel->glibc API work. > > I've got some performance testing to do in this space (primarily of the VRULL implementations).  It's just going to take a long time to get the data.  And that implementation probably needs some revamping after all the work on the mem* and str* infrastructure that landed earlier this year. > I don't think glibc is the right place for code dump, specially for implementations that does not have representative performance numbers in real hardware and might require further tuning. It can be even tricky if you require different build config to testing as used to have for some ABI (for instance on powerpc with --with-cpu), at least for ifunc we have some mechanism to test multiple variants assuming the chips at least support (which should be case for unaligned). For ARM we have the optimize-routines [1] project, where we use as testbed for multiple implementations and also, due its license mechanism, make it easier to implement the optimized routines on different projects. We used to have a similar project, cortex-strings, on Linaro. So for experimental routines, where you expect to have frequent tuning based on once you have tested and benchmarks on different chips; an external project might a better idea; and sync with glibc once the routines are tested and validate. And these RISCV does seemed to be still very experimental, where performance numbers are still synthetic ones from emulators. Another possibility might to improve the generic implementation, as we have done recently where RISCV bitmanip was a matter to add just 2 files and 4 functions to optimize multiple string functions [2]. I have some WIP patches to add support for unaligned memcpy/memmove with a very simple strategy. [1] https://github.com/ARM-software/optimized-routines [2] https://sourceware.org/git/?p=glibc.git;a=commit;h=25788431c0f5264c4830415de0cdd4d9926cbad9