From: Ingo Molnar <mingo@kernel.org>
To: Andy Lutomirski <luto@kernel.org>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Jan Kara <jack@suse.cz>, Borislav Petkov <bp@alien8.de>,
Denys Vlasenko <dvlasenk@redhat.com>
Subject: Re: [PATCH] x86: Fix detection of GCC -mpreferred-stack-boundary support
Date: Mon, 6 Jul 2015 15:44:24 +0200 [thread overview]
Message-ID: <20150706134423.GA8094@gmail.com> (raw)
In-Reply-To: <e5297c192969adfa0d28b84cf8a22d59573db26d.1436126872.git.luto@kernel.org>
* Andy Lutomirski <luto@kernel.org> wrote:
> As per https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383, GCC only
> allows -mpreferred-stack-boundary=3 on x86_64 if -mno-sse is set.
> That means that cc-option will not detect
> -mpreferred-stack-boundary=3 support, because we test for it before
> setting -mno-sse.
>
> Fix it by reordering the Makefile bits.
>
> Compile-tested only. This should help avoid code generation issues
> such as the one that was worked around in b96fecbfa8c8 ("x86/fpu:
> Fix boot crash in the early FPU code").
>
> I'm a bit concerned that we could still have problems on older GCC
> versions given that our asm code does not respect GCC's idea of the
> ABI-required stack alignment.
>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Borislav Petkov <bp@alien8.de>
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> ---
> arch/x86/Makefile | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> index 118e6debc483..344dd2110b2a 100644
> --- a/arch/x86/Makefile
> +++ b/arch/x86/Makefile
> @@ -39,6 +39,12 @@ ifdef CONFIG_X86_NEED_RELOCS
> LDFLAGS_vmlinux := --emit-relocs
> endif
>
> +# prevent gcc from generating any FP code by mistake
> +# This must be before we try -mpreferred-stack-boundary -- see
> +# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383
> +KBUILD_CFLAGS += -mno-sse -mno-mmx -mno-sse2 -mno-3dnow
> +KBUILD_CFLAGS += $(call cc-option,-mno-avx,)
> +
So the 'stack boundary' is the RSP that GCC generates before it calls another
function from within an existing function, right?
So looking at this I question the choice of -mpreferred-stack-boundary=3. Why not
do -mpreferred-stack-boundary=2?
My reasoning: on modern uarchs there's no penalty for 32-bit misalignment of
64-bit variables, only if they cross 64-byte cache lines, which should be rare
with a chance of 1:16. This small penalty (of at most +1 cycle in some
circumstances IIRC) should be more than counterbalanced by the compression of the
stack by 5% on average.
... using stack-boundary=1 or stack-boundary=0 would probably be
counterproductive, as these more exotic misalignments get treated progressively
worse by x86 CPUs.
... but I have not measured any of this and even the 5% is just a possibly
overoptimistic guess.
Thanks,
Ingo
next prev parent reply other threads:[~2015-07-06 13:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-05 20:08 [PATCH] x86: Fix detection of GCC -mpreferred-stack-boundary support Andy Lutomirski
2015-07-06 13:44 ` Ingo Molnar [this message]
2015-07-06 16:59 ` Andy Lutomirski
2015-07-06 17:40 ` Ingo Molnar
2015-07-06 17:59 ` Andy Lutomirski
2015-07-07 4:01 ` Raymond Jennings
2015-07-06 17:10 ` Linus Torvalds
2015-07-06 17:32 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150706134423.GA8094@gmail.com \
--to=mingo@kernel.org \
--cc=bp@alien8.de \
--cc=dvlasenk@redhat.com \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.