add a config option for -Os compilation
Subsystems (2)
PATCH 1/1 add a config option for -Os compilation
Hi Andrew,
the patch below adds a configuration option for -Os (the H8300 symbol is similar to the symbols on other architectures). It includes the results of all detail discussions and applies, compiles and works with 2.6.0-test7-mm1.
Could you add it to -mm?
diffstat output:
Makefile | 8 +++++++- arch/arm/Makefile | 2 -- arch/h8300/Kconfig | 4 ++++ arch/h8300/Makefile | 3 +-- init/Kconfig | 10 ++++++++++ 5 files changed, 22 insertions(+), 5 deletions(-)
TIA
Adrian
init/Kconfig renamed from init/Kconfig.old +10 -0
@@ -65,6 +65,16 @@ menu "General setup" +config CC_OPTIMIZE_FOR_SIZE + bool "Optimize for size" if EXPERIMENTAL + default y if ARM || H8300 + default n + help + Enabling this option will pass "-Os" instead of "-O2" to gcc + resulting in a smaller kernel. + + If unsure, say N. + config SWAP bool "Support for paging of anonymous memory" depends on MMU
Makefile renamed from Makefile.old +7 -1
@@ -274,7 +274,7 @@ CPPFLAGS := -D__KERNEL__ -Iinclude \ $(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include) -CFLAGS := -Wall -Wstrict-prototypes -Wno-trigraphs -O2 \ +CFLAGS := -Wall -Wstrict-prototypes -Wno-trigraphs \ -fno-strict-aliasing -fno-common AFLAGS := -D__ASSEMBLY__
@@ -421,6 +421,12 @@ # --------------------------------------------------------------------------- +ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE +CFLAGS += -Os +else +CFLAGS += -O2 +endif + ifndef CONFIG_FRAME_POINTER CFLAGS += -fomit-frame-pointer endif
arch/arm/Makefile renamed from arch/arm/Makefile.old +0 -2
@@ -14,8 +14,6 @@ GZFLAGS :=-9 #CFLAGS +=-pipe -CFLAGS :=$(CFLAGS:-O2=-Os) - ifeq ($(CONFIG_FRAME_POINTER),y) CFLAGS +=-fno-omit-frame-pointer -mapcs -mno-sched-prolog endif
arch/h8300/Kconfig renamed from arch/h8300/Kconfig.old +4 -0
@@ -5,6 +5,10 @@ mainmenu "uClinux/h8300 (w/o MMU) Kernel Configuration" +config H8300 + bool + default y + config MMU bool default n
arch/h8300/Makefile renamed from arch/h8300/Makefile.old +1 -1
@@ -34,7 +34,7 @@ ldflags-$(CONFIG_CPU_H8S) := -mh8300self CFLAGS += $(cflags-y) -CFLAGS += -mint32 -fno-builtin -Os +CFLAGS += -mint32 -fno-builtin CFLAGS += -g CFLAGS += -D__linux__ CFLAGS += -DUTS_SYSNAME=\"uClinux\"
Quoted 2 lines · Adrian Bunk
the patch below adds a configuration option for -Os
Two problems:
a) It adds yet another reason why person A discovers problems which person B cannot reproduce.
b) It adds yet another reason why person A cannot work out the exact file-n-line where person B's kernel oopsed.
They are small concerns really, but it does make one wonder why we should not make this change unconditional: just switch the kernel to -Os?
Does anyone have any (non-micro-)benchmark results which say this is a bad idea?
Quoted 6 lines · Andrew Morton
...
They are small concerns really, but it does make one wonder why we should not make this change unconditional: just switch the kernel to -Os?Does anyone have any (non-micro-)benchmark results which say this is a bad idea?
No benchmarks, only arguments:
- it's less tested (there might be miscompilations in some part of the kernel with some supported compilers)
- there might be fast path code somewhere in the kernel that becomes significantely slower with -Os
- I've already seen a report for an ICE in gcc 2.95 of a user compiling kernel 2.4 with -Os [1]
cu
Adrian
[1] http://bugs.debian.org/213497
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedQuoted 6 lines · Adrian Bunk
Quoted 4 lines · Andrew Morton
...
They are small concerns really, but it does make one wonder why we should not make this change unconditional: just switch the kernel to -Os?
Quoted 7 lines
Quoted 2 lines
Does anyone have any (non-micro-)benchmark results which say this is a bad idea?
No benchmarks, only arguments:
- it's less tested (there might be miscompilations in some part of the kernel with some supported compilers)
Testing is not a problem.
Quoted 2 lines
- there might be fast path code somewhere in the kernel that becomes significantely slower with -Os
I really doubt it. Kernel CPU footprint is dominated by dcache misses. If -Os reduces icache footprint it may even be a net win; people tend to benchmark things in tight loops, which favours fast code over small code.
Quoted 2 lines
- I've already seen a report for an ICE in gcc 2.95 of a user compiling kernel 2.4 with -Os [1]
Well there's only one way to find out if we'll hit that. How's about you cook me a patch which switches to -Os unconditionally and we'll see how it goes?
Quoted 4 lines · Andrew Morton
...
I really doubt it. Kernel CPU footprint is dominated by dcache misses. If -Os reduces icache footprint it may even be a net win; people tend to benchmark things in tight loops, which favours fast code over small code.
The main effect of -Os compared to -O2 (besides disabling some reordering of the code and prefetching) is the disabling of various alignments. I doubt that's a win on all CPUs.
Quoted 6 lines
Quoted 2 lines
- I've already seen a report for an ICE in gcc 2.95 of a user compiling kernel 2.4 with -Os [1]
Well there's only one way to find out if we'll hit that. How's about you cook me a patch which switches to -Os unconditionally and we'll see how it goes?
I still dislike it, but the patch is below.
cu
Adrian
arch/arm/Makefile renamed from arch/arm/Makefile.old +0 -2
@@ -14,8 +14,6 @@ GZFLAGS :=-9 #CFLAGS +=-pipe -CFLAGS :=$(CFLAGS:-O2=-Os) - ifeq ($(CONFIG_FRAME_POINTER),y) CFLAGS +=-fno-omit-frame-pointer -mapcs -mno-sched-prolog endif
arch/h8300/Makefile renamed from arch/h8300/Makefile.old +1 -1
@@ -34,7 +34,7 @@ ldflags-$(CONFIG_CPU_H8S) := -mh8300self CFLAGS += $(cflags-y) -CFLAGS += -mint32 -fno-builtin -Os +CFLAGS += -mint32 -fno-builtin CFLAGS += -g CFLAGS += -D__linux__ CFLAGS += -DUTS_SYSNAME=\"uClinux\"
Makefile renamed from Makefile.old +1 -1
@@ -275,7 +275,7 @@ CPPFLAGS := -D__KERNEL__ -Iinclude \ $(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include) -CFLAGS := -Wall -Wstrict-prototypes -Wno-trigraphs -O2 \ +CFLAGS := -Wall -Wstrict-prototypes -Wno-trigraphs -Os \ -fno-strict-aliasing -fno-common AFLAGS := -D__ASSEMBLY__
Quoted 8 lines
Quoted 3 lines
I really doubt it. Kernel CPU footprint is dominated by dcache misses. If -Os reduces icache footprint it may even be a net win; people tend to benchmark things in tight loops, which favours fast code over small code.
The main effect of -Os compared to -O2 (besides disabling some reordering of the code and prefetching) is the disabling of various alignments. I doubt that's a win on all CPUs.
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
- I've already seen a report for an ICE in gcc 2.95 of a user compiling kernel 2.4 with -Os [1]
Well there's only one way to find out if we'll hit that. How's about you cook me a patch which switches to -Os unconditionally and we'll see how it goes?
I still dislike it, but the patch is below.
Please don't - I benchmarked it a while ago, and it's definitely slower. If you have a puny 128K L2 cache, it might help, but it definitely needs to be optional.
M.
Quoted 2 lines · Martin J. Bligh
Please don't - I benchmarked it a while ago, and it's definitely slower.
Alan said he generally found -Os to be faster...
Quoted 5 lines · Andrew Morton
Quoted 2 lines · Martin J. Bligh
Please don't - I benchmarked it a while ago, and it's definitely slower.
Alan said he generally found -Os to be faster...
Not exactly:
http://www.ussg.iu.edu/hypermail/linux/kernel/0211.0/1513.html
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedQuoted 11 lines · Adrian Bunk
Quoted 5 lines · Andrew Morton
Quoted 2 lines · Martin J. Bligh
Please don't - I benchmarked it a while ago, and it's definitely slower.
Alan said he generally found -Os to be faster...
Not exactly:
http://www.ussg.iu.edu/hypermail/linux/kernel/0211.0/1513.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0308.1/1261.html
And bear in mind that you can see significant changes in benchmark results between equivalent kernels even when the optimisation level is kept the same, due to aliasing and alignment luck.
It would take a quite a lot of work to measure this properly. A simple A/B comparison doesn't cut it.
Quoted 11 lines
Quoted 10 lines · Andrew Morton
Quoted 5 lines
Quoted 2 lines · Martin J. Bligh
Please don't - I benchmarked it a while ago, and it's definitely slower.
Alan said he generally found -Os to be faster...
Not exactly:
http://www.ussg.iu.edu/hypermail/linux/kernel/0211.0/1513.html
Quoted 8 lines
http://www.ussg.iu.edu/hypermail/linux/kernel/0308.1/1261.html
And bear in mind that you can see significant changes in benchmark results between equivalent kernels even when the optimisation level is kept the same, due to aliasing and alignment luck.
It would take a quite a lot of work to measure this properly. A simple A/B comparison doesn't cut it.
So why are we changing it then? ;-) We don't seem to have much evidence either way. What are the distros doing?
M.
Quoted 3 lines · Martin J. Bligh
...
So why are we changing it then? ;-) We don't seem to have much evidence either way. What are the distros doing?
The exact speed differences need measurements and it might be that depending on the gcc version and hardware the one or the other is faster.
I doubt it would make a noticalble difference in either direction for an average user who runs Mozilla under KDE. -O2 is IMHO the better default since it's well tested through different gcc versions.
The more important point is that -Os code is significantely smaller which is important for some applications (e.g. a router-on-a-floppy or small embedded systems).
Quoted 1 line
M.
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedQuoted 2 lines · Martin J. Bligh
So why are we changing it then? ;-) We don't seem to have much evidence either way. What are the distros doing?
in the context of boot/rescuefloppies (yes those pesky black things still exist) I would seriously consider -Os, esp if there's no big peformance disadvantage....
Quoted 5 lines · Martin J. Bligh
Quoted 3 lines
It would take a quite a lot of work to measure this properly. A simple A/B comparison doesn't cut it.
So why are we changing it then? ;-)
It is very easy to demonstrate that it saves 300 kilobytes of memory.
Quoted 8 lines
Quoted 5 lines · Martin J. Bligh
Quoted 3 lines
It would take a quite a lot of work to measure this properly. A simple A/B comparison doesn't cut it.
So why are we changing it then? ;-)
It is very easy to demonstrate that it saves 300 kilobytes of memory.
OK, fair enough - so can we either do:
1) a config option
or
2) if you hate that, at least switch it to -O2 on CONFIG_SMP, on the grounds that such systems generally have larger caches, and plenty of RAM.
M.
On Sat, 2003-10-18 12:21:27 +0200, Adrian Bunk <[email protected]> wrote in message <[email protected]>:
Quoted 8 lines · Andrew Morton
Quoted 3 lines
I really doubt it. Kernel CPU footprint is dominated by dcache misses. If -Os reduces icache footprint it may even be a net win; people tend to benchmark things in tight loops, which favours fast code over small code.
The main effect of -Os compared to -O2 (besides disabling some reordering of the code and prefetching) is the disabling of various alignments. I doubt that's a win on all CPUs.
I definively *like* to see -Os be configureable by user. It's *big* win for a lowmem system. There, the actual "running speed" may be limited by HDD swap speed, and having a smaller kernel means having more pages left to luserspace...
MfG, JBG
Signature · 4 lines
Jan-Benedict Glaw [email protected] . +49-172-7608481 "Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));