From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751385AbdIORUz (ORCPT ); Fri, 15 Sep 2017 13:20:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55524 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750865AbdIORUy (ORCPT ); Fri, 15 Sep 2017 13:20:54 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1DC80272A3 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jpoimboe@redhat.com Date: Fri, 15 Sep 2017 12:20:52 -0500 From: Josh Poimboeuf To: Andrey Ryabinin Cc: Linus Torvalds , the arch/x86 maintainers , Linux Kernel Mailing List , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , Andy Lutomirski , Alexander Potapenko , Dmitriy Vyukov , Matthias Kaehlcke , Arnd Bergmann , Peter Zijlstra Subject: Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent Message-ID: <20170915172052.5kmtzjk44dywk2k6@treble> References: <20fac125eed15c916f684e27dfca753d524c6725.1504186968.git.jpoimboe@redhat.com> <20170831172542.k5qchwmgckdcnc6d@treble> <96dcfb0d-75b9-9707-67df-9bae33186b7d@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <96dcfb0d-75b9-9707-67df-9bae33186b7d@virtuozzo.com> User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 15 Sep 2017 17:20:54 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 15, 2017 at 07:53:46PM +0300, Andrey Ryabinin wrote: > > > On 08/31/2017 08:25 PM, Josh Poimboeuf wrote: > > > > There have been a few other ideas which have *almost* worked: > > > > 1) Make the 'register void *__sp asm(_ASM_SP)' a global variable instead > > of a local one. This works for GCC and doesn't break clang. However > > it resulted in a lot of changed code on the GCC side. It looked like > > some optimizations had been disabled, even in functions which > > shouldn't have been affected. > > > > (For those who wasn't following previous discussion there is the patch - http://lkml.kernel.org/r/<75850bb7-a60e-057d-d88b-afa0c79e94a0@gmail.com> > But, Josh discovered that the patch causes regression in .text size with gcc > 7.x > http://lkml.kernel.org/r/<20170721132452.ihpws67e3e7ym3al@treble> ) > > I'm not so sure that this is disabled optimization. I assume that global rsp makes > changes something in gcc's register allocation logic, or something like that leading > to subtle changes in generated code. > > But what I recently find out, is that this "regression" sometimes is actually improvement in .text size. > It all depends on .config, e.g: > > > allnoconfig: > text data bss dec hex filename > patched 938094 207700 1215752 2361546 2408ca allnoconfig_p/vmlinux > unpatched 938768 211796 1215752 2366316 241b6c allnoconfig/vmlinux > > > defconfig: > text data bss dec hex filename > patched 10691469 4882856 876544 16450869 fb0535 defconfig_p/vmlinux > unpatched 10691035 4882856 876544 16450435 fb0383 defconfig/vmlinux > > allyesconfig: > text data bss dec hex filename > patched 159216239 153294411 49692672 362203322 1596c8ba allyesconfig_p/vmlinux > unpatched 159224951 153294387 49692672 362212010 1596eaaa allyesconfig/vmlinux > > > So there is regression with Josh's config and defconfig, but allnoconfig and allyesconfig shows improvement. > Note that sometimes there is the difference in .data size too, don't ask me why. > > Given that, perhaps the best thing to do here would be asking gcc devs why is generated code changed. > And if such changes are harmless (as I suspect) we can just fix the problem with this simple patch http://lkml.kernel.org/r/<75850bb7-a60e-057d-d88b-afa0c79e94a0@gmail.com> ? > Despite the increased .text on some configs. Can you change all the other code sites in a similar way, and then run the numbers again? $ git grep __sp |grep register |grep void arch/x86/include/asm/alternative.h: register void *__sp asm(_ASM_SP); \ arch/x86/include/asm/mshyperv.h: register void *__sp asm(_ASM_SP); arch/x86/include/asm/mshyperv.h: register void *__sp asm(_ASM_SP); arch/x86/include/asm/paravirt_types.h: register void *__sp asm("esp") arch/x86/include/asm/paravirt_types.h: register void *__sp asm("rsp") arch/x86/include/asm/preempt.h: register void *__sp asm(_ASM_SP); \ arch/x86/include/asm/preempt.h: register void *__sp asm(_ASM_SP); \ arch/x86/include/asm/processor.h: register void *__sp asm(_ASM_SP); arch/x86/include/asm/rwsem.h: register void *__sp asm(_ASM_SP); \ arch/x86/include/asm/uaccess.h: register void *__sp asm(_ASM_SP); \ arch/x86/include/asm/xen/hypercall.h: register void *__sp asm(_ASM_SP); arch/x86/kvm/emulate.c: register void *__sp asm(_ASM_SP); arch/x86/kvm/vmx.c: register void *__sp asm(_ASM_SP); arch/x86/mm/fault.c: register void *__sp asm("rsp"); -- Josh