From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E9FD5C433E0 for ; Wed, 20 Jan 2021 07:59:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9BBC923159 for ; Wed, 20 Jan 2021 07:59:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730210AbhATH6r (ORCPT ); Wed, 20 Jan 2021 02:58:47 -0500 Received: from cmyk.emenem.pl ([217.79.154.63]:34474 "EHLO smtp.emenem.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730282AbhATH4w (ORCPT ); Wed, 20 Jan 2021 02:56:52 -0500 X-Virus-Scanned: amavisd-new at emenem.pl Received: from [192.168.1.10] (50-78-106-33-static.hfc.comcastbusiness.net [50.78.106.33]) (authenticated bits=0) by cmyk.emenem.pl (8.15.2/8.15.2) with ESMTPSA id 10K7pY7U020705 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Wed, 20 Jan 2021 08:51:36 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ans.pl; s=20190507; t=1611129098; bh=UKvDotcD+dWv0G1iUeqG4pW8YJnJrX7YOEAsqojYKLY=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Etg5C7FKQ3TBVFDspkZuyk/OMPGILLDnupPNN7jL6pxot+yDkfQf/a0kjgHmbAumv pD1zAUBkJbH+n7ymEb5yPx00Niu1LDSxmKpgkDi3zSsheWRg9ZkQKyvsTi+X84+fMj IGEq5fZeM2SQXysbtP+hfz080P5coBKczbgGEfbg= Subject: Re: [PATCH v2 0/4] x86/fpu: Reduce unnecessary FNINIT and MXCSR usage To: Andy Lutomirski , x86@kernel.org Cc: LKML , Krzysztof Mazur , Arnd Bergmann References: From: =?UTF-8?Q?Krzysztof_Ol=c4=99dzki?= Message-ID: Date: Tue, 19 Jan 2021 23:51:32 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021-01-19 at 09:38, Andy Lutomirski wrote: > This series fixes two regressions: a boot failure on AMD K7 and a > performance regression on everything. > > I did a double-take here -- the regressions were reported by different > people, both named Krzysztof :) > > Changes from v1: > - Fix MMX better -- MMX really does need FNINIT. > - Improve the EFI code. > - Rename the KFPU constants. > - Changelog improvements. > > Andy Lutomirski (4): > x86/fpu: Add kernel_fpu_begin_mask() to selectively initialize state > x86/mmx: Use KFPU_387 for MMX string operations > x86/fpu: Make the EFI FPU calling convention explicit > x86/fpu/64: Don't FNINIT in kernel_fpu_begin() Hi Andy. I have quickly tested the new version on E3-1280 V2. * 5.10.9 + 7ad816762f9bf89e940e618ea40c43138b479e10 reverted (aka unfixed) xor: measuring software checksum speed avx : 38616 MB/sec prefetch64-sse : 25797 MB/sec generic_sse : 23147 MB/sec xor: using function: avx (38616 MB/sec) * 5.10.9 (the original) xor: measuring software checksum speed avx : 23318 MB/sec prefetch64-sse : 22562 MB/sec generic_sse : 20431 MB/sec xor: using function: avx (23318 MB/sec) * 5.10.9 + "Reduce unnecessary FNINIT and MXCSR usage" v2 xor: measuring software checksum speed avx : 26451 MB/sec prefetch64-sse : 25777 MB/sec generic_sse : 23178 MB/sec xor: using function: avx (26451 MB/sec) Overall, kernel xor benchmark reports better performance on 5.10.9 than on 5.4.90 (see my prev e-mail), but the general trend is the same. The "unfixed" kernel is much faster for all of avx, prefetch64-sse and generic_sse. With the fix, we see the expected perf regression. Now, with your patchset, both prefetch64-sse and generic_sse are able to recover the full performance, as seen on 5.4. However, this is not the case for avx. While there is still an improvement, it is nowhere close to where it used to be. I wonder why AVX still sees a regression and if anything more can be done about it? Will do more tests tomorrow. Thanks, Krzysztof