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.9 required=3.0 tests=BAYES_00, 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 75C90C433E7 for ; Thu, 3 Sep 2020 07:21:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3812820737 for ; Thu, 3 Sep 2020 07:21:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726054AbgICHU6 (ORCPT ); Thu, 3 Sep 2020 03:20:58 -0400 Received: from pegase1.c-s.fr ([93.17.236.30]:53672 "EHLO pegase1.c-s.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726022AbgICHU6 (ORCPT ); Thu, 3 Sep 2020 03:20:58 -0400 Received: from localhost (mailhub1-int [192.168.12.234]) by localhost (Postfix) with ESMTP id 4BhsfY3bm4zB09Zf; Thu, 3 Sep 2020 09:20:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at c-s.fr Received: from pegase1.c-s.fr ([192.168.12.234]) by localhost (pegase1.c-s.fr [192.168.12.234]) (amavisd-new, port 10024) with ESMTP id z990iF4fMPYf; Thu, 3 Sep 2020 09:20:53 +0200 (CEST) Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192]) by pegase1.c-s.fr (Postfix) with ESMTP id 4BhsfY2h7WzB09ZZ; Thu, 3 Sep 2020 09:20:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 5F8A78B7B1; Thu, 3 Sep 2020 09:20:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at c-s.fr Received: from messagerie.si.c-s.fr ([127.0.0.1]) by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id GoY3tY2xK-tx; Thu, 3 Sep 2020 09:20:54 +0200 (CEST) Received: from [192.168.4.90] (unknown [192.168.4.90]) by messagerie.si.c-s.fr (Postfix) with ESMTP id A1A698B790; Thu, 3 Sep 2020 09:20:53 +0200 (CEST) Subject: Re: [PATCH 10/10] powerpc: remove address space overrides using set_fs() To: Linus Torvalds Cc: Christoph Hellwig , Al Viro , Michael Ellerman , the arch/x86 maintainers , linux-fsdevel , linux-arch , linuxppc-dev , Kees Cook , Linux Kernel Mailing List References: <20200827150030.282762-1-hch@lst.de> <20200827150030.282762-11-hch@lst.de> <8974838a-a0b1-1806-4a3a-e983deda67ca@csgroup.eu> <20200902123646.GA31184@lst.de> From: Christophe Leroy Message-ID: <6a6ea160-a661-4a15-777c-e26a487829d4@csgroup.eu> Date: Thu, 3 Sep 2020 09:20:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Sender: linux-arch-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org Le 02/09/2020 à 20:02, Linus Torvalds a écrit : > On Wed, Sep 2, 2020 at 8:17 AM Christophe Leroy > wrote: >> >> >> With this fix, I get >> >> root@vgoippro:~# time dd if=/dev/zero of=/dev/null count=1M >> 536870912 bytes (512.0MB) copied, 6.776327 seconds, 75.6MB/s >> >> That's still far from the 91.7MB/s I get with 5.9-rc2, but better than >> the 65.8MB/s I got yesterday with your series. Still some way to go thought. > > I don't see why this change would make any difference. > Neither do I. Looks like nowadays, CONFIG_STACKPROTECTOR has become a default. I rebuilt the kernel without it, I now get a throughput of 99.8MB/s both without and with this series. Looking at the generated code (GCC 10.1), a small change in a function seems to make large changes in the generated code when CONFIG_STACKPROTECTOR is set. In addition to that, trivial functions which don't use the stack at all get a stack frame anyway when CONFIG_STACKPROTECTOR is set, allthough that's only -fstack-protector-strong. And there is no canary check. Without CONFIG_STACKPROTECTOR: c01572a0 : c01572a0: 38 60 ff ff li r3,-1 c01572a4: 38 80 ff e3 li r4,-29 c01572a8: 4e 80 00 20 blr With CONFIG_STACKPROTECTOR (regardless of CONFIG_STACKPROTECTOR_STRONG or not): c0164e08 : c0164e08: 94 21 ff f0 stwu r1,-16(r1) c0164e0c: 38 60 ff ff li r3,-1 c0164e10: 38 80 ff e3 li r4,-29 c0164e14: 38 21 00 10 addi r1,r1,16 c0164e18: 4e 80 00 20 blr Wondering why CONFIG_STACKPROTECTOR has become the default. It seems to imply a 10% performance loss even in the best case (91.7MB/s versus 99.8MB/s) Note that without CONFIG_STACKPROTECTOR_STRONG, I'm at 99.3MB/s, so that's really the _STRONG alternative that hurts. Christophe