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: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-4.2 required=3.0 tests=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 [8.43.85.97]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 1AB1E1F619 for ; Tue, 17 Mar 2020 13:17:14 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D3F983937420; Tue, 17 Mar 2020 13:17:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D3F983937420 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1584451032; bh=RHsNhIkE54AxQXikrDtmio3g5vui092EoPgAFKdRh6g=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=UWoIHUJqfnlFlOsCJN+YTcA47qkvV6+r/6znAcQl+wPjyTwfESLjSZknsuDh/1IUl 8nZS+UhWeGLdhI0tiS2VErPqoRxxuwrq8UYu8hVEOu/WsnP9BNIKWPTYnuxaqZhIUe 4o6T36calmUEanWALeZEMa1wLxvbRy6E7LfFdm1M= Received: from us-smtp-delivery-74.mimecast.com (us-smtp-delivery-74.mimecast.com [216.205.24.74]) by sourceware.org (Postfix) with ESMTP id 6130F3899401 for ; Tue, 17 Mar 2020 13:17:10 +0000 (GMT) Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-321-sQEjcl3CO3as2uCBmqoxRw-1; Tue, 17 Mar 2020 09:17:03 -0400 X-MC-Unique: sQEjcl3CO3as2uCBmqoxRw-1 Received: by mail-qt1-f199.google.com with SMTP id y11so21029916qtn.3 for ; Tue, 17 Mar 2020 06:17:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=RHsNhIkE54AxQXikrDtmio3g5vui092EoPgAFKdRh6g=; b=Xfe7N/J/REAWVv0U0XuNA//z+IPKA4uHUFh3lYqmbWxKilSZEjUEZSxf/zuzBI71+k fhPRZ4LpYot8hRRUjzkmzkP22Lne0/WniJPwUcWR+7BlPE+3qeJm0vw8kUu0pwyJQ+w0 UTVZJofFnAfIfiw+iOadRxnJorgvSwan5qWbaWTcwkaQszJxklC6pqhkLckOgpPtBK8e 27sSPgrqFvouU5uvrWcD1gJbkJ002MvBOni4qi7CpeY7mu3WA1Zs0/2Yr3P4i+soPyOP /qsDfelX1KzbaOeDOC7nxhTHlAriVl+3AJLq8QielialnlwP6UnYPGMcTWcc5T4QTFou S1YQ== X-Gm-Message-State: ANhLgQ2xJsNNf0a7DYaW1jSU54BW8bhTEa7Sfp2Rp5yExKODDhduigMf PpDMDPDitgPnj+CKOdcduEl5hRzJwusCLnkhD0b/ZQf+AtPP0EfPj9/w0Eq/x2UWxPburtgp3I+ co1rfQdgYKd4NHlKEKVql X-Received: by 2002:ac8:4d09:: with SMTP id w9mr5294098qtv.279.1584451023008; Tue, 17 Mar 2020 06:17:03 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvRhG3G/mZSBJG7hehvKQwNzj3/P51gHfmX11LzPE5HCTKE1EyTJXQwvELuXeEG+A0L6xydSA== X-Received: by 2002:ac8:4d09:: with SMTP id w9mr5294063qtv.279.1584451022656; Tue, 17 Mar 2020 06:17:02 -0700 (PDT) Received: from [192.168.1.4] (198-84-170-103.cpe.teksavvy.com. [198.84.170.103]) by smtp.gmail.com with ESMTPSA id h5sm1850759qkc.118.2020.03.17.06.17.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Mar 2020 06:17:01 -0700 (PDT) Subject: Re: [PATCH 0/3] RFC: Platform Support for AMD Zen and AVX2/AVX To: Florian Weimer , Prem Mallappa via Libc-alpha References: <20200317044646.29707-1-PMallappa@amd.com> <87wo7je4me.fsf@mid.deneb.enyo.de> Organization: Red Hat Message-ID: <6a5b92f9-31d9-01c6-e6c6-acf1554e4458@redhat.com> Date: Tue, 17 Mar 2020 09:17:00 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <87wo7je4me.fsf@mid.deneb.enyo.de> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Carlos O'Donell via Libc-alpha Reply-To: Carlos O'Donell Cc: codonell@redhat.com, Michael Matz , Prem Mallappa , Prem Mallappa , schwab@suse.com Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" 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. > 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. > (I already have the trimmed-down list from Intel.) > -- Cheers, Carlos.