From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 62DB2385841E for ; Fri, 7 Jul 2023 16:07:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 62DB2385841E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com Received: from pps.filterd (m0360072.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 367FlqqD022057; Fri, 7 Jul 2023 16:07:40 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pp1; bh=A85kaj2OjTYdA8AJfiJ2BZ05s5LQjg2ZDqgnfHC8abo=; b=AFZb4fTCOw0m9SZSoqH2Cu2cUHMBiB71+8BIgZBaZnDki1SReKEN8BxcmzrWU3jsoBqR XNZFU0Obyad/jr2QCs1NhCaFTs96ZPWxJmzfyJp3fSQgQQ08sOLttSYiu/D1yQkETMWu gVVYkrc9K/yqN4muPkB3rGVc+jd/+iIUnbYaHhx9hVLKdm9XLwT3trRsBq68HZk6o2BT 2sxXRocvJI7cR64c+URFlZ8nvOCEiyvlJFuxsjRXBagmSVSwtrqbn0CpaVDilqXz5Gg7 xtmQvpBnem9hyPpdA1yJ9jT3IpkZwC7HkkKlGGMBbBbpT4ZI7SqUnE/OH97SRjLlBRFq 9Q== Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3rpnnh8f99-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Jul 2023 16:07:40 +0000 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 367FQIqD008571; Fri, 7 Jul 2023 16:07:39 GMT Received: from smtprelay05.dal12v.mail.ibm.com ([9.208.130.101]) by ppma01dal.us.ibm.com (PPS) with ESMTPS id 3rjbs6pq10-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Jul 2023 16:07:39 +0000 Received: from smtpav06.dal12v.mail.ibm.com (smtpav06.dal12v.mail.ibm.com [10.241.53.105]) by smtprelay05.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 367G7b0n51970440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 7 Jul 2023 16:07:37 GMT Received: from smtpav06.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 80F3E58055; Fri, 7 Jul 2023 16:07:37 +0000 (GMT) Received: from smtpav06.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1F31858043; Fri, 7 Jul 2023 16:07:37 +0000 (GMT) Received: from [9.61.25.68] (unknown [9.61.25.68]) by smtpav06.dal12v.mail.ibm.com (Postfix) with ESMTP; Fri, 7 Jul 2023 16:07:37 +0000 (GMT) Message-ID: <31ceaf3a-6471-b31a-c059-969341353195@linux.ibm.com> Date: Fri, 7 Jul 2023 11:07:36 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v3] PowerPC: Influence cpu/arch hwcap features via GLIBC_TUNABLES. Content-Language: en-US To: Adhemerval Zanella Netto , bmahi496@linux.ibm.com, libc-alpha@sourceware.org Cc: rajis@linux.ibm.com, Mahesh Bodapati References: <20230706122544.175643-1-bmahi496@linux.ibm.com> <67b984d4-211f-3116-828f-6b62700bb5b3@linux.ibm.com> <6b225ce2-429b-5af7-2097-58fb0e871e80@linaro.org> From: Peter Bergner In-Reply-To: <6b225ce2-429b-5af7-2097-58fb0e871e80@linaro.org> Content-Type: text/plain; charset=UTF-8 X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: eY8iTd8n2_Zu4QLO9yzEnuyNxgLXlmpG X-Proofpoint-GUID: eY8iTd8n2_Zu4QLO9yzEnuyNxgLXlmpG Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-07-07_10,2023-07-06_02,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 phishscore=0 adultscore=0 mlxscore=0 clxscore=1015 mlxlogscore=999 spamscore=0 suspectscore=0 impostorscore=0 bulkscore=0 lowpriorityscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2307070149 X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,KAM_SHORT,NICE_REPLY_A,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 7/7/23 9:25 AM, Adhemerval Zanella Netto wrote: > The set_hwcaps is called once only at process execution. Adding bits might > make sense in a scenario that you are running a new glibc on older kernels > and you know that some string routines are safe to run on that hardware > (although it might come with some caveats, since it might still require some > kernel support). AIUI, on Power, the firmware (which knows about the "new" hardware features on the cpu we're running on) passes the HWCAP/HWCAP2 masks to the kernel. The kernel (old or new) then places those masks (even the new ones it doesn't know about/understand) into the AUXV that is passed to glibc, so we don't have a problem with "old" kernels and the HWCAP/HWCAP2 masks glibc receives from the kernel should be "full-featured" wrt the cpu it is running on. This is why I was mentioning I'm not sure supporting adding bits to the masks makes any sense on Power, unless there is a mechanism where we might have removed some earlier. It sounds like from your comment that there isn't a way for that to happen. That said, keeping the tunable API the same across the different architectures the same is important, so we should at least accept the user trying...it just won't do anything. :-) > With this patch GLIBC_TUNABLES=glibc.cpu.hwcaps=feature is ignored if 'feature' > is not support by HWCAP/2, which is not explicit state in documentation and > it slight differ from s390x/x86. The s390x only considers features that are > used in ifunc resolver, but since the idea is to use __builtin_cpu_supports > maybe powerpc should handle everything. Since our (old or new) kernel supplied HWCAP/HWCAP2 masks are full-featured, it makes sense on Power not to allow users to set any bits that were not set in the original hwcap masks, since we "know" the underlying hardware doesn't support them. I believe Mahesh's current patch only supports modifying the internal to glibc ifunc resolvers, but I do want them to eventually be made externally available for use by the __builtin_cpu_supports() built-in. > It also bothers me that our documentation references to a source file to > actually get the supported 'features' strings. I think we can make it better > and proper document the correct list of features and maybe add a ld.so > option to also print the supported values. I like that idea. That said, GCC documents the 'features' as part of the __builtin_cpu_supports built-in documentation: https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Basic-PowerPC-Built-in-Functions-Available-on-all-Configurations.html ...but the user should be able to get this from glibc documentation since the tunables is a glibc feature (wow, too many features :-). Peter