From: Nicolas Pitre <nico@fluxnic.net>
To: Will Deacon <will.deacon@arm.com>
Cc: "Catalin Marinas" <catalin.marinas@arm.com>,
"Måns Rullgård" <mans@mansr.com>,
linux-arm-kernel@lists.infradead.org,
lkml <linux-kernel@vger.kernel.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
sam@ravnborg.org, ak@linux.intel.com
Subject: Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP
Date: Thu, 26 May 2011 17:03:39 -0400 (EDT) [thread overview]
Message-ID: <alpine.LFD.2.00.1105261650330.3207@xanadu.home> (raw)
In-Reply-To: <1306429854.26735.9.camel@e102144-lin.cambridge.arm.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1896 bytes --]
On Thu, 26 May 2011, Will Deacon wrote:
> This issue seems to be caused by passing -fconserve-stack to GCC. This
> was added in 8f7f5c9f ("kbuild: set -fconserve-stack option for gcc
> 4.5") and as you can see from the archive:
>
> http://lkml.org/lkml/2009/9/20/39
>
> it was thought to only have an impact on inlining decisions. Looking at
> the documentation for GCC 4.6:
>
> -fconserve-stack
> Attempt to minimize stack usage. The compiler will attempt to
> use less stack space, even if that makes the program slower. This option
> implies setting the ‘large-stack-frame’ parameter to 100 and the
> ‘large-stack-frame-growth’ parameter to 400.
>
> So it sounds like we might not want to enable this blindly across all
> architectures. Indeed, on ARM, it encourages the compiler to pack
> variables on the stack which leads to the weird and wonderful alignment
> situation that has been encountered in this thread.
>
> Can we remove -fconserve-stack from the top-level Makefile (or at least
> make it conditional by architecture)?
I think this is an orthogonal issue.
My opinion is that we should use -mno-unaligned-access by default on
ARM. The reason is that we've been expecting the compiler not to cause
unaligned accesses for ages, and letting the compiler, for whatever
reasons including things like -fconserve-stack, produce unaligned
accesses behind our back is a change in behavior we might not always be
prepared for. Unaligned accesses in the kernel should be rare anyway,
and allowing the compiler to generate them can be allowed for selected
files when proven beneficial.
It is possible that -fconserve-stack is still valuable on ARM given that
it is also used with -mno-unaligned-access for other things than
structure packing on the stack, and therefore its merits can be debated
independently from the alignment issue at hand.
Nicolas
WARNING: multiple messages have this Message-ID (diff)
From: nico@fluxnic.net (Nicolas Pitre)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP
Date: Thu, 26 May 2011 17:03:39 -0400 (EDT) [thread overview]
Message-ID: <alpine.LFD.2.00.1105261650330.3207@xanadu.home> (raw)
In-Reply-To: <1306429854.26735.9.camel@e102144-lin.cambridge.arm.com>
On Thu, 26 May 2011, Will Deacon wrote:
> This issue seems to be caused by passing -fconserve-stack to GCC. This
> was added in 8f7f5c9f ("kbuild: set -fconserve-stack option for gcc
> 4.5") and as you can see from the archive:
>
> http://lkml.org/lkml/2009/9/20/39
>
> it was thought to only have an impact on inlining decisions. Looking at
> the documentation for GCC 4.6:
>
> -fconserve-stack
> Attempt to minimize stack usage. The compiler will attempt to
> use less stack space, even if that makes the program slower. This option
> implies setting the ?large-stack-frame? parameter to 100 and the
> ?large-stack-frame-growth? parameter to 400.
>
> So it sounds like we might not want to enable this blindly across all
> architectures. Indeed, on ARM, it encourages the compiler to pack
> variables on the stack which leads to the weird and wonderful alignment
> situation that has been encountered in this thread.
>
> Can we remove -fconserve-stack from the top-level Makefile (or at least
> make it conditional by architecture)?
I think this is an orthogonal issue.
My opinion is that we should use -mno-unaligned-access by default on
ARM. The reason is that we've been expecting the compiler not to cause
unaligned accesses for ages, and letting the compiler, for whatever
reasons including things like -fconserve-stack, produce unaligned
accesses behind our back is a change in behavior we might not always be
prepared for. Unaligned accesses in the kernel should be rare anyway,
and allowing the compiler to generate them can be allowed for selected
files when proven beneficial.
It is possible that -fconserve-stack is still valuable on ARM given that
it is also used with -mno-unaligned-access for other things than
structure packing on the stack, and therefore its merits can be debated
independently from the alignment issue at hand.
Nicolas
next prev parent reply other threads:[~2011-05-26 21:03 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-23 11:16 [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP Catalin Marinas
2011-05-23 12:30 ` Måns Rullgård
2011-05-23 13:25 ` Russell King - ARM Linux
2011-05-23 13:21 ` Russell King - ARM Linux
2011-05-23 13:51 ` Catalin Marinas
2011-05-23 14:37 ` Måns Rullgård
2011-05-23 14:41 ` Catalin Marinas
2011-05-23 14:52 ` Russell King - ARM Linux
2011-05-24 9:39 ` Catalin Marinas
2011-05-24 14:17 ` Måns Rullgård
2011-05-24 15:26 ` Catalin Marinas
2011-05-24 16:23 ` Måns Rullgård
2011-05-24 17:26 ` Nicolas Pitre
2011-05-24 17:13 ` Dave Martin
2011-05-25 11:14 ` Catalin Marinas
2011-05-25 12:43 ` Dave Martin
2011-05-25 13:32 ` Måns Rullgård
2011-05-25 14:05 ` Dave Martin
2011-05-25 14:48 ` Måns Rullgård
2011-05-25 14:50 ` Catalin Marinas
2011-05-25 14:53 ` Måns Rullgård
2011-05-26 17:10 ` Will Deacon
2011-05-26 17:10 ` Will Deacon
2011-05-26 18:14 ` Måns Rullgård
2011-05-26 18:14 ` Måns Rullgård
2011-05-26 19:58 ` Andi Kleen
2011-05-26 19:58 ` Andi Kleen
2011-05-26 21:03 ` Nicolas Pitre [this message]
2011-05-26 21:03 ` Nicolas Pitre
2011-05-26 21:10 ` Andi Kleen
2011-05-26 21:10 ` Andi Kleen
2011-05-26 21:26 ` Måns Rullgård
2011-05-26 21:26 ` Måns Rullgård
2011-05-27 10:05 ` Will Deacon
2011-05-27 10:05 ` Will Deacon
2011-05-27 16:53 ` Andi Kleen
2011-05-27 16:53 ` Andi Kleen
2011-05-26 21:51 ` Russell King - ARM Linux
2011-05-26 21:51 ` Russell King - ARM Linux
2011-05-26 22:29 ` Andi Kleen
2011-05-26 22:29 ` Andi Kleen
2011-05-27 8:38 ` Catalin Marinas
2011-05-27 8:38 ` Catalin Marinas
2011-05-27 8:54 ` Russell King - ARM Linux
2011-05-27 8:54 ` Russell King - ARM Linux
2011-05-27 9:51 ` Catalin Marinas
2011-05-27 9:51 ` Catalin Marinas
2011-05-27 9:56 ` Catalin Marinas
2011-05-27 9:56 ` Catalin Marinas
2011-05-27 12:46 ` Måns Rullgård
2011-05-27 12:46 ` Måns Rullgård
2011-05-28 15:34 ` [PATCH] Disable -fconserve-stack on ARM Andi Kleen
2011-05-28 15:34 ` Andi Kleen
2011-05-31 16:30 ` Catalin Marinas
2011-05-31 16:30 ` Catalin Marinas
2011-05-31 18:01 ` Andi Kleen
2011-05-31 18:01 ` Andi Kleen
2011-06-02 13:08 ` Catalin Marinas
2011-06-02 13:08 ` Catalin Marinas
[not found] <mailman.254.1306496353.1533.linux-arm-kernel@lists.infradead.org>
2011-05-27 12:14 ` [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP Frank Hofmann
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=alpine.LFD.2.00.1105261650330.3207@xanadu.home \
--to=nico@fluxnic.net \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mans@mansr.com \
--cc=sam@ravnborg.org \
--cc=will.deacon@arm.com \
/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.