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 B78F41F619 for ; Tue, 17 Mar 2020 21:37:19 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9371D3ADC0B9; Tue, 17 Mar 2020 21:37:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9371D3ADC0B9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1584481038; bh=md8vuQabuaqudls9AthoK9qJkVjxt4ShyCcFMWM6B6k=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=XVJr53QBTYCHv8589UpyFoNYUBcwBhrcz+DMTxZEp6dklWwbJl6Qckz82nqls8i1O 2jpYfp9wfeo0baekqDgdzZupzT46M+UGSsNpRdmdt08YtDIb2hk3I1Ei+GPl0i26CA ORuePsCy1ArV/NksY3mZBACH290Hz5UoG7xWle3I= 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 437553ADC0AF for ; Tue, 17 Mar 2020 21:37:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 437553ADC0AF Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-391-OwFY3MPtPHmhdwFoo_ZXBg-1; Tue, 17 Mar 2020 17:37:09 -0400 X-MC-Unique: OwFY3MPtPHmhdwFoo_ZXBg-1 Received: by mail-qv1-f69.google.com with SMTP id ee5so19062840qvb.23 for ; Tue, 17 Mar 2020 14:37:08 -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:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=md8vuQabuaqudls9AthoK9qJkVjxt4ShyCcFMWM6B6k=; b=Y1b8+7L8jsT84mU23Jfo8tGMld2OqaZDLZSxQ/HwegqjrgPr8FS3F5VwLP9u4OiJDR BDIxDVeMDU05DJ+7QAYptu5pNwWt7UWSVfBcwzsJ9s223x/JKp6UmGxhBX5O1hldcSsZ ejWF7VAacg9h/HH+LjKNdLJNaWgx99AMMcBHbaDLp64VBf5Mfog4rQRUSW1K1oP5wKyG nR9SuSxuZeSU1GtQjPe1C3099ZQzWl+Nl1Ws8Yj4J1v4WdPy4m1PKzMYVuNqCZVikr7Q zob5wwKRuRBiTS/qV52s3tnFfA/nlqZNtJP8T97+00BczJfBxa2VH9fS5S0+JL/GaS1h TohQ== X-Gm-Message-State: ANhLgQ013TB1UbBGmp0rAuYR16PtBnLyzamKZAfMWJfZaUnvY1zVls4F ahIn9pwlLLMJWCBovN15Stp7kJu5PC1u2S31DbfOtjIVNemr1m1HddcSGv5f8ryUbx2cxJL8RtG +dfesbiHNxKbbIEKlgvDC X-Received: by 2002:a37:5b82:: with SMTP id p124mr1035664qkb.130.1584481028133; Tue, 17 Mar 2020 14:37:08 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsZfe4esfr0Xg1lmOs2HlB7KmfeSks4xNGGby92UyFZ56ro072NsrwP9/jk7/42mol178DFRg== X-Received: by 2002:a37:5b82:: with SMTP id p124mr1035651qkb.130.1584481027869; Tue, 17 Mar 2020 14:37:07 -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 128sm2773408qki.103.2020.03.17.14.37.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Mar 2020 14:37:07 -0700 (PDT) Subject: Re: [PATCH 0/3] RFC: Platform Support for AMD Zen and AVX2/AVX To: Adhemerval Zanella , libc-alpha@sourceware.org References: <20200317044646.29707-1-PMallappa@amd.com> <87wo7je4me.fsf@mid.deneb.enyo.de> <6a5b92f9-31d9-01c6-e6c6-acf1554e4458@redhat.com> Organization: Red Hat Message-ID: <11fbb273-bced-f806-d949-3a3bd2f54818@redhat.com> Date: Tue, 17 Mar 2020 17:37:05 -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: 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 Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On 3/17/20 3:27 PM, Adhemerval Zanella via Libc-alpha wrote: > On 17/03/2020 10:17, Carlos O'Donell via Libc-alpha wrote: >> 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? It should be subject to change just like tunables. It should be an optimization, and not a requirement, and applications should always provide a fallback implementaiton to allow the application to load. Failure to load the libraries *may* result in a failure to start the application and we need to be OK with that. That is to say that a particularly package may only ship an optimized library (going against the recommendation). We should verify that downstream distributions can use /etc/ld.so.conf as a way to add back directories into the search of the existing additional multilib search directories e.g. Add back /lib64/haswell for a few years. Does that answer your question? > 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. Yes. >> 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])? In the end I think we'll want: (a) Try CPU vendor directories first. - Each vendor should name their directories and the explicit compiler options to target them (printed by LD_DEBUG). (b) Try shared directories second. - Based on a common set of identified features. - Compiler options to target the shared set should be explicitly stated (printed by LD_DEBUG). My understanding is that Florian is asking for help with (b) to identify what things should be enabled for current CPUs, and that we'll compare that list to the Intel list and make a common shared directory that the downstream distributions can used for the most optimized library we can have in common. What we can do: - Cleanup the generic code to allow a CPU vendor split? - We have a mix of hwcap bit handling and list handling for platforms. This is also a bit messy. - Allow vendors to drop in their CPU vendor search list ahead of the shared list, again based on feature presence. - Prepare the code for a shared common directory based on some shared subset of features, and enable it only if those features are present. Today doing this is a bit messy in cpu-features.c. > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=24080 -- Cheers, Carlos.