Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1732863pxf; Fri, 26 Mar 2021 13:37:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxjy6yyDZrCfDVRmbHLPmJM+5CsospQW9UpThuS8VEtQnNb7oJZI9IwtFlAyig/UPQKiKsU X-Received: by 2002:a17:906:260a:: with SMTP id h10mr17483308ejc.392.1616791020125; Fri, 26 Mar 2021 13:37:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616791020; cv=none; d=google.com; s=arc-20160816; b=wG1YFoncPB/Q20KT8RSN/AlH7F/gI13AJ79Anf/R5J6m9nIa+mf6HePIrBQpB8HvjY Z6fNJvCqF9uaFpG9yZttn8dp+aH+JWKPdttLA6av/ypdPWlJ/ohp+M332cyHYGhNf68v VYTDS7aTJGjhvH3QxM6m/rip7BGafwrQuGYiY1JNnwsEOwqcwfpnM0uwEKGxA+AV9kqR DdmmydVNMrGZMXuhcGSBAETe/bhXr/V8b3ywftJqnOCjeordM7eNTOqy6Mz4U0NtumR+ Y9kf6XLZdfdyZEmSJYXBZWaglcep6kuoz1RGO5+XSiTPM5/34lft48EzBW4bA6xW1uj0 OTjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:in-reply-to:date:references:subject:cc:to:from; bh=MYb02mBi5Vu2HFoI66TKuOkdSnMR0mHkorq+ua3p28g=; b=QeZH+UAWGsGcScuEV3mH/kd3U2CQ8MMICdnuPoUZZIGDO39sE3pACKOaEEA8VlEKlo BOEoFKgdaSrCxqxL8fSkpNz07C15U9Ol7XIBZzmFs8lz52nYTR4wpt50ytUyUsaHNC81 xMl+DSuCzOp3+S5eA3UMYv66KhofUquHaD/8U2U0cK9HB5m6vZ12teygikx3wSwQCnaR A5/eneyglQORfKr66TVn2edJGG2liHYUSWWjxWbUdt4mH9TAThskvT4qwG+FM9QSYCHV MKqySWDgm1jtzpWmb9FiPkDrCWRJ8mHOODLsnzsCRLNWHRFZYKvwSih1SBZs+U98xkyv y4bQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hs11si9104054ejc.375.2021.03.26.13.36.37; Fri, 26 Mar 2021 13:37:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230106AbhCZUfn convert rfc822-to-8bit (ORCPT + 99 others); Fri, 26 Mar 2021 16:35:43 -0400 Received: from albireo.enyo.de ([37.24.231.21]:55738 "EHLO albireo.enyo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230003AbhCZUfe (ORCPT ); Fri, 26 Mar 2021 16:35:34 -0400 Received: from [172.17.203.2] (port=40449 helo=deneb.enyo.de) by albireo.enyo.de ([172.17.140.2]) with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1lPtB0-00038H-F0; Fri, 26 Mar 2021 20:35:26 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1lPtB0-0008Aa-CB; Fri, 26 Mar 2021 21:35:26 +0100 From: Florian Weimer To: Andy Lutomirski Cc: "H. J. Lu" , X86 ML , LKML , "Bae\, Chang Seok" , "Carlos O'Donell" , Rich Felker , libc-alpha Subject: Re: Why does glibc use AVX-512? References: <87a6qqi064.fsf@mid.deneb.enyo.de> <87blb5d7zx.fsf@mid.deneb.enyo.de> Date: Fri, 26 Mar 2021 21:35:26 +0100 In-Reply-To: (Andy Lutomirski's message of "Fri, 26 Mar 2021 12:47:42 -0700") Message-ID: <877dltd569.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Andy Lutomirski: > On Fri, Mar 26, 2021 at 12:34 PM Florian Weimer wrote: >> x86: Sporadic failures in tst-cpu-features-cpuinfo >> > > It's worth noting that recent microcode updates have make RTM > considerably less likely to actually work on many parts. It's > possible you should just disable it. :( Sorry, I'm not sure who should disable it. Let me sum up the situation: We have a request for a performance enhancement in glibc, so that applications can use it on server parts where RTM actually works. For CPUs that support AVX-512, we may be able to meet that with a change that uses the new 256-bit registers, t avoid the %xmm transition penalty. (This is the easy case, hopefully—there shouldn't be any frequency issues associated with that, and if the kernel doesn't optimize the context switch today, that's a nonissue as well.) For CPUs that do not support AVX-512 but support RTM (and AVX2), we need a dynamic run-time check whether the string function is invoked in a transaction. In that case, we need to use VZEROALL instead of VZEROUPPER. (It's apparently too costly to issue VZEROALL unconditionally.) All this needs to work transparently without user intervention. We cannot require firmware upgrades to fix the incorrect RTM reporting issue (the bug I referenced). I think we can require software updates which tell glibc when to use RTM-enabled string functions if the dynamic selection does not work (either for performance reasons, or because of the RTM reporting bug). I want to avoid a situation where one in eight processes fail to work correctly because the CPUID checks ran on CPU 0, where RTM is reported as available, and then we trap when executing XTEST on other CPUs.