From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 78AD61F619 for ; Tue, 17 Mar 2020 19:27:11 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3F4E03943543; Tue, 17 Mar 2020 19:27:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3F4E03943543 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1584473230; bh=V1bwqTDiTAfoqnMnJq6yn0N92QEc3Z0Ddu0lk5yBwQU=; h=To:References:Subject:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=EkgkIr6JZlCfELz0knyeiV61jgcNfYp4VVQcU3c/ZpE76CXIj4cr+sEgnwQgxclrI 33OqHjmbis3622AdTc80vVDsTboZwnUDjKDIsSmjwbnSbrO6CPn9wnlt0JkFZw0Lqt cS/UQS5hMQpbWbyR15OHnoKaTsA1HUwh0wVKYhD8= Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) by sourceware.org (Postfix) with ESMTPS id 7109D393743A for ; Tue, 17 Mar 2020 19:27:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7109D393743A Received: by mail-qk1-x741.google.com with SMTP id u25so34631062qkk.3 for ; Tue, 17 Mar 2020 12:27:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:from:autocrypt:subject:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=V1bwqTDiTAfoqnMnJq6yn0N92QEc3Z0Ddu0lk5yBwQU=; b=jXgNOoGDVNpVXtpD8kTKjid6dXTm35/bW6BI3jyjoe3qM7BR4rAC4n+JodaNxuGlUT wh42+WfO3bqzir96QlQBXsJcyBDSf3x6HkuymuPfX4WCIrcI2+qXcIdv13bvrGuN5svI YaeNIiwPgDPvsX55zj8qaJ+6ywvWB8hrYBMdpdw6ocd1KUU4vJRsDO8Fkr6qoqYybrvt v8jlaghIMgsP8rJC+hGaY/VPPsXK34Y8lqZVIt9C9MNcMaXwa8ALDglzU9/bmMTxX1NX w7gCTE8Ai3vvf74i4Jc/A0KVg5Y21/lBASGRP44AxP8OqA/jyO4FKpB/0LYVcFRuyXCT JHLw== X-Gm-Message-State: ANhLgQ2yjl7u8LemVUUEBvqP9UpGtGEP6zxUsUvyjfV9/qUpjrFyC54a d0K/+gL/uWWxrotSyQxe5WihqAa9Tyc= X-Google-Smtp-Source: ADFU+vtbcGP2f/VGY2uk1nig8jqIcXIz3UPXAOgPe8izQVUjslQkMUeZdoloLub3xrv2WWdn27BGXg== X-Received: by 2002:a37:7744:: with SMTP id s65mr398788qkc.405.1584473225581; Tue, 17 Mar 2020 12:27:05 -0700 (PDT) Received: from [192.168.1.4] ([177.194.48.209]) by smtp.googlemail.com with ESMTPSA id l16sm2964457qtc.73.2020.03.17.12.27.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Mar 2020 12:27:05 -0700 (PDT) To: libc-alpha@sourceware.org References: <20200317044646.29707-1-PMallappa@amd.com> <87wo7je4me.fsf@mid.deneb.enyo.de> <6a5b92f9-31d9-01c6-e6c6-acf1554e4458@redhat.com> Autocrypt: addr=adhemerval.zanella@linaro.org; prefer-encrypt=mutual; keydata= xsFNBFcVGkoBEADiQU2x/cBBmAVf5C2d1xgz6zCnlCefbqaflUBw4hB/bEME40QsrVzWZ5Nq 8kxkEczZzAOKkkvv4pRVLlLn/zDtFXhlcvQRJ3yFMGqzBjofucOrmdYkOGo0uCaoJKPT186L NWp53SACXguFJpnw4ODI64ziInzXQs/rUJqrFoVIlrPDmNv/LUv1OVPKz20ETjgfpg8MNwG6 iMizMefCl+RbtXbIEZ3TE/IaDT/jcOirjv96lBKrc/pAL0h/O71Kwbbp43fimW80GhjiaN2y WGByepnkAVP7FyNarhdDpJhoDmUk9yfwNuIuESaCQtfd3vgKKuo6grcKZ8bHy7IXX1XJj2X/ BgRVhVgMHAnDPFIkXtP+SiarkUaLjGzCz7XkUn4XAGDskBNfbizFqYUQCaL2FdbW3DeZqNIa nSzKAZK7Dm9+0VVSRZXP89w71Y7JUV56xL/PlOE+YKKFdEw+gQjQi0e+DZILAtFjJLoCrkEX w4LluMhYX/X8XP6/C3xW0yOZhvHYyn72sV4yJ1uyc/qz3OY32CRy+bwPzAMAkhdwcORA3JPb kPTlimhQqVgvca8m+MQ/JFZ6D+K7QPyvEv7bQ7M+IzFmTkOCwCJ3xqOD6GjX3aphk8Sr0dq3 4Awlf5xFDAG8dn8Uuutb7naGBd/fEv6t8dfkNyzj6yvc4jpVxwARAQABzUlBZGhlbWVydmFs IFphbmVsbGEgTmV0dG8gKExpbmFybyBWUE4gS2V5KSA8YWRoZW1lcnZhbC56YW5lbGxhQGxp bmFyby5vcmc+wsF3BBMBCAAhBQJXFRpKAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJ EKqx7BSnlIjv0e8P/1YOYoNkvJ+AJcNUaM5a2SA9oAKjSJ/M/EN4Id5Ow41ZJS4lUA0apSXW NjQg3VeVc2RiHab2LIB4MxdJhaWTuzfLkYnBeoy4u6njYcaoSwf3g9dSsvsl3mhtuzm6aXFH /Qsauav77enJh99tI4T+58rp0EuLhDsQbnBic/ukYNv7sQV8dy9KxA54yLnYUFqH6pfH8Lly sTVAMyi5Fg5O5/hVV+Z0Kpr+ZocC1YFJkTsNLAW5EIYSP9ftniqaVsim7MNmodv/zqK0IyDB GLLH1kjhvb5+6ySGlWbMTomt/or/uvMgulz0bRS+LUyOmlfXDdT+t38VPKBBVwFMarNuREU2 69M3a3jdTfScboDd2ck1u7l+QbaGoHZQ8ZNUrzgObltjohiIsazqkgYDQzXIMrD9H19E+8fw kCNUlXxjEgH/Kg8DlpoYJXSJCX0fjMWfXywL6ZXc2xyG/hbl5hvsLNmqDpLpc1CfKcA0BkK+ k8R57fr91mTCppSwwKJYO9T+8J+o4ho/CJnK/jBy1pWKMYJPvvrpdBCWq3MfzVpXYdahRKHI ypk8m4QlRlbOXWJ3TDd/SKNfSSrWgwRSg7XCjSlR7PNzNFXTULLB34sZhjrN6Q8NQZsZnMNs TX8nlGOVrKolnQPjKCLwCyu8PhllU8OwbSMKskcD1PSkG6h3r0AqzsFNBFcVGkoBEACgAdbR Ck+fsfOVwT8zowMiL3l9a2DP3Eeak23ifdZG+8Avb/SImpv0UMSbRfnw/N81IWwlbjkjbGTu oT37iZHLRwYUFmA8fZX0wNDNKQUUTjN6XalJmvhdz9l71H3WnE0wneEM5ahu5V1L1utUWTyh VUwzX1lwJeV3vyrNgI1kYOaeuNVvq7npNR6t6XxEpqPsNc6O77I12XELic2+36YibyqlTJIQ V1SZEbIy26AbC2zH9WqaKyGyQnr/IPbTJ2Lv0dM3RaXoVf+CeK7gB2B+w1hZummD21c1Laua +VIMPCUQ+EM8W9EtX+0iJXxI+wsztLT6vltQcm+5Q7tY+HFUucizJkAOAz98YFucwKefbkTp eKvCfCwiM1bGatZEFFKIlvJ2QNMQNiUrqJBlW9nZp/k7pbG3oStOjvawD9ZbP9e0fnlWJIsj 6c7pX354Yi7kxIk/6gREidHLLqEb/otuwt1aoMPg97iUgDV5mlNef77lWE8vxmlY0FBWIXuZ yv0XYxf1WF6dRizwFFbxvUZzIJp3spAao7jLsQj1DbD2s5+S1BW09A0mI/1DjB6EhNN+4bDB SJCOv/ReK3tFJXuj/HbyDrOdoMt8aIFbe7YFLEExHpSk+HgN05Lg5TyTro8oW7TSMTk+8a5M kzaH4UGXTTBDP/g5cfL3RFPl79ubXwARAQABwsFfBBgBCAAJBQJXFRpKAhsMAAoJEKqx7BSn lIjvI/8P/jg0jl4Tbvg3B5kT6PxJOXHYu9OoyaHLcay6Cd+ZrOd1VQQCbOcgLFbf4Yr+rE9l mYsY67AUgq2QKmVVbn9pjvGsEaz8UmfDnz5epUhDxC6yRRvY4hreMXZhPZ1pbMa6A0a/WOSt AgFj5V6Z4dXGTM/lNManr0HjXxbUYv2WfbNt3/07Db9T+GZkpUotC6iknsTA4rJi6u2ls0W9 1UIvW4o01vb4nZRCj4rni0g6eWoQCGoVDk/xFfy7ZliR5B+3Z3EWRJcQskip/QAHjbLa3pml xAZ484fVxgeESOoaeC9TiBIp0NfH8akWOI0HpBCiBD5xaCTvR7ujUWMvhsX2n881r/hNlR9g fcE6q00qHSPAEgGr1bnFv74/1vbKtjeXLCcRKk3Ulw0bY1OoDxWQr86T2fZGJ/HIZuVVBf3+ gaYJF92GXFynHnea14nFFuFgOni0Mi1zDxYH/8yGGBXvo14KWd8JOW0NJPaCDFJkdS5hu0VY 7vJwKcyHJGxsCLU+Et0mryX8qZwqibJIzu7kUJQdQDljbRPDFd/xmGUFCQiQAncSilYOcxNU EMVCXPAQTteqkvA+gNqSaK1NM9tY0eQ4iJpo+aoX8HAcn4sZzt2pfUB9vQMTBJ2d4+m/qO6+ cFTAceXmIoFsN8+gFN3i8Is3u12u8xGudcBPvpoy4OoG Subject: Re: [PATCH 0/3] RFC: Platform Support for AMD Zen and AVX2/AVX Message-ID: Date: Tue, 17 Mar 2020 16:27:02 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <6a5b92f9-31d9-01c6-e6c6-acf1554e4458@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Adhemerval Zanella via Libc-alpha Reply-To: Adhemerval Zanella Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On 17/03/2020 10:17, Carlos O'Donell via Libc-alpha wrote: > On 3/17/20 5:02 AM, Florian Weimer wrote: >> * Prem Mallappa via Libc-alpha: >> >>> From: Prem Mallappa >>> >>> Hello Glibc Community, >>> >>> == (cross posting to libc-alpha, apologies for the spam) == >>> >>> This is in response to >>> >>> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=24979 >>> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=24080 >>> [3] https://sourceware.org/bugzilla/show_bug.cgi?id=23249 >>> >>> It is clear that there is no panacea here. However, >>> here is an attempt to address them in parts. >>> >>> From [1], enable customers who already have >>> "haswell" libs and has seen perf benifits by loading >>> them on AMD Zen. >>> (Load libraries by placing them in LD_LIBRARY_PATH/zen >>> or by a symbolic link zen->haswell) >>> >>> From [2] and [3] >>> And, A futuristic generic-avx2/generic-avx libs, >>> enables OS vendors to supply an optimized set. >>> And haswell/zen are really a superset, hence >>> keeping it made sense. >>> >>> By this we would like to open it up for discussion >>> The haswell/zen can be intel/amd >>> (or any other name, and supply ifunc based loading >>> internally) >> >> I think we cannot use the platform subdirectory for that because there >> is just a single one. If we want a Intel/AMD split, we need to >> enhance the dynamic loader to try the CPU vendor directory first, and >> then fallback to a shared subdirectory. Most distributions do not >> want to test and ship binaries specific to Intel or AMD CPUs. > > I agree. The additional burden on testing, maintaining, and supporting > distinct libraries is not feasible. > >> That's a generic loader change which will need some time to implement, >> but we can work on something else in the meantime: >> >> We need to check for *all* relevant CPU flags such code can use and, >> and only enable a subdirectory if they are present. This is necessary >> because virtualization and microcode updates can disable individual >> CPU features. > > Agreed. This is the only sensible plan. The platform directories already > imply some of this, but it's not well structured. Which should be our policy regarding the platform name over releases? Should the names set in previous release being supported in a compatibility manner or should it not be constraint (as for tunables) and subject of change? If the former, with a defined subset of the CPU features flags it might be possible to share folder over x86 chips without using chips release names. > >> For the new shared subdirectory, I think we should not restrict >> ourselves just to AVX2, but we should also include useful extensions >> that are in practice always implemented in silicon along with AVX2, >> but can be separately tweaked. > > Agreed. > >> This seems to be a reasonable list of CPU feature flags to start with: >> >> 3DNOW >> 3DNOWEXT >> 3DNOWPREFETCH >> ABM >> ADX >> AES >> AVX >> AVX2 >> BMI >> BMI2 >> CET >> CLFLUSH >> CLFLUSHOPT >> CLWB >> CLZERO >> CMPXCHG16B >> ERMS >> F16C >> FMA >> FMA4 >> FSGSBASE >> FSRM >> FXSR >> HLE >> LAHF >> LZCNT >> MOVBE >> MWAITX >> PCLMUL >> PCOMMIT >> PKU >> POPCNT >> PREFETCHW >> RDPID >> RDRAND >> RDSEED >> RDTSCP >> RTM >> SHA >> SSE3 >> SSE4.1 >> SSE4.2 >> SSE4A >> SSSE3 >> TSC >> XGETBV >> XSAVE >> XSAVEC >> XSAVEOPT >> XSAVES >> >> You (as in AMD) need to go through this list and come back with the >> subset that you think should be enabled for current and future CPUs, >> based on your internal roadmap and known errata for existing CPUs. We >> do not need a rationale for how you filter down the list, merely the >> outcome. > > And this is the hard part that we can't solve without AMD's help. > > Even if you ignore "future CPUs" it would be useful to get this list > for all current CPUs given your architectural knowledge, errata, and > other factors like microcode, that covers the currently released CPUs. So the question is how should be move forward: let the chip vendor (Intel, AMD, etc.) define its own naming scheme based on its own chip roadmap, or create subsets of features to set a common naming folder (as suggested by Richard Biener on BZ#24080 [1])? [1] https://sourceware.org/bugzilla/show_bug.cgi?id=24080