Add option to build with -O3
PATCH 1/1 Add option to build with -O3
--- Makefile | 2 ++ init/Kconfig | 19 ++++++++++++++++--- 2 files changed, 18 insertions(+), 3 deletions(-)
Makefile +2 -0
@@ -581,6 +581,8 @@ all: vmlinux ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE KBUILD_CFLAGS += -Os $(call cc-disable-warning,maybe-uninitialized,) +else ifdef CONFIG_CC_OPTIMIZE_FOR_SPEED +KBUILD_CFLAGS += -O3 else KBUILD_CFLAGS += -O2 endif
init/Kconfig +16 -3
@@ -1233,13 +1233,26 @@ source "usr/Kconfig" endif +choice + prompt "Optimize" + +config CC_OPTIMIZE_NORMAL + bool "Optimize Normal (-O2)" + help + Enabling this option will pass "-O2" to gcc config CC_OPTIMIZE_FOR_SIZE - bool "Optimize for size" + bool "Optimize for size (-Os)" help - Enabling this option will pass "-Os" instead of "-O2" to gcc + Enabling this option will pass "-Os" to gcc resulting in a smaller kernel. - If unsure, say N. +config CC_OPTIMIZE_FOR_SPEED + bool "Optimze for speed (-O3)" + help + Enabling this option will pass "-O3" to gcc + resulting in a larger kernel (but possibly faster) + +endchoice config SYSCTL bool
--
1.8.5.4
The information contained in this transmission may contain confidential information. If the reader of this message is not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
init/Kconfig source "usr/Kconfig" · line 1253
Quoted 5 lines · Jon Ringle
init/Kconfig +5
-0+config CC_OPTIMIZE_FOR_SPEED + bool "Optimze for speed (-O3)" + help + Enabling this option will pass "-O3" to gcc + resulting in a larger kernel (but possibly faster)
Are you sure about that? Have you measured it?
Quoted 8 lines · Greg KH
init/Kconfig source "usr/Kconfig" · line 1253
Quoted 5 lines · Jon Ringle
init/Kconfig +5
-0+config CC_OPTIMIZE_FOR_SPEED + bool "Optimze for speed (-O3)" + help + Enabling this option will pass "-O3" to gcc + resulting in a larger kernel (but possibly faster)Are you sure about that? Have you measured it?
I do know that there is an improvement performance-wise for my particular use-case.
My target is an ARM board being built with gcc-4.8.2. My board has on it a sc16is740 that is used as an RS-485 port. The sc16is740 is on the i2c bus, so when an interrupt comes in to indicate that there is data available to be read, I need to get the data over the i2c bus. I do this on a kthread to do this work. The i2c transactions (using i2c-davinci driver) are also interrupt driven. I was seeing a lot of lost packets when receiving data at only 19200. Adding the -O3 compile option helped in this regard in that I am now rarely seeing packet loss.
Jon
The information contained in this transmission may contain confidential information. If the reader of this message is not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Quoted 1 line · Jon Ringle
The information contained in this transmission may contain confidential information. If the reader of this message is not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Because of this footer, I must destroy this message, kernel development is not confidental.
Quoted 6 lines · Greg KH
Quoted 1 line · Jon Ringle
The information contained in this transmission may contain confidential information. If the reader of this message is not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Because of this footer, I must destroy this message, kernel development is not confidental.
Obviously, this is a footer that is not added by me, but rather the mail server I am sending this message through. Besides, the footer indates it "may contain confidential information". The key word being *may*. Of course kernel development is never confidential and the content of any transmission done to the lkml is of public record. You and anyone who cares to read/comment this message on lkml is indeed the inteded recipient, therefore there is no need to destroy this message :)
I sure hope your response was just in jest :)
Jon
The information contained in this transmission may contain confidential information. If the reader of this message is not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Quoted 11 lines · Jon Ringle
Quoted 6 lines · Greg KH
Quoted 1 line · Jon Ringle
The information contained in this transmission may contain confidential information. If the reader of this message is not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
Because of this footer, I must destroy this message, kernel development is not confidental.
Quoted 7 lines
Obviously, this is a footer that is not added by me, but rather the mail server I am sending this message through. Besides, the footer indates it "may contain confidential information". The key word being *may*. Of course kernel development is never confidential and the content of any transmission done to the lkml is of public record. You and anyone who cares to read/comment this message on lkml is indeed the inteded recipient, therefore there is no need to destroy this message :)
But how do I know for sure that there isn't anything confidential in it?
Quoted 1 line
I sure hope your response was just in jest :)
Sadly, no, I have been advised that I am not supposed to respond to messages with footers like that, and I am not allowed to take patches with them either.
Now, I'm ignoring the first part (responding) to help you learn why your patches will proabably always be ignored, please work to remove that from your email server.
good luck,
greg k-h
Quoted 2 lines · Jon Ringle
If you are not the intended recipient, please contact the sender by reply
email and destroy all copies of the original message.
Is your company willing to indemnify my organization for the costs of tracking down *all* copies of the message (including, but not restricted to, those on backup tapes, copies automatically committed to WORM-based compliance stores by our mail system, and already logically deleted but not yet overwritten blocks on disk), and securely clearing the data sufficient to prevent its recovery by an experienced forensics analyst armed with a subpoena and a "preserve evidence" order?
And does your company's clientele realize that in case of a miscue on the part of one of your staff, you're relying on an unknown third party's good will to secure their confidential information, instead of relying on actual cryptography to secure their data?
Quoted 16 lines · Jon Ringle
Quoted 8 lines · Greg KH
init/Kconfig source "usr/Kconfig" · line 1253
Quoted 5 lines · Jon Ringle
init/Kconfig +5
-0+config CC_OPTIMIZE_FOR_SPEED + bool "Optimze for speed (-O3)" + help + Enabling this option will pass "-O3" to gcc + resulting in a larger kernel (but possibly faster)Are you sure about that? Have you measured it?
I do know that there is an improvement performance-wise for my particular use-case.
Quoted 8 lines
My target is an ARM board being built with gcc-4.8.2. My board has on it a sc16is740 that is used as an RS-485 port. The sc16is740 is on the i2c bus, so when an interrupt comes in to indicate that there is data available to be read, I need to get the data over the i2c bus. I do this on a kthread to do this work. The i2c transactions (using i2c-davinci driver) are also interrupt driven. I was seeing a lot of lost packets when receiving data at only 19200. Adding the -O3 compile option helped in this regard in that I am now rarely seeing packet loss.
Please also see:
http://www.gossamer-threads.com/lists/linux/kernel/1835761?do=post_view_threaded#1835761
Signature · 2 lines
Thanks, //richard
Quoted 28 lines · Richard Weinberger
Quoted 15 lines · Jon Ringle
Quoted 7 lines · Greg KH
Quoted 4 lines · Jon Ringle
+config
CC_OPTIMIZE_FOR_SPEED+ bool "Optimze for speed
(-O3)" + help + Enabling this option will pass "-O3"
to gcc + resulting in a larger kernel (but possibly
faster)Are you sure about that? Have you measured it?
I do know that there is an improvement performance-wise for my particular use-case.
Quoted 10 lines
My target is an ARM board being built with gcc-4.8.2. My board has on it a sc16is740 that is used as an RS-485 port. The sc16is740 is on the i2c bus, so when an interrupt comes in to indicate that there is data available to be read, I need to get the data over the i2c bus. I do this on a kthread to do this work. The i2c transactions (using i2c-davinci driver) are also interrupt driven. I was seeing a lot of lost packets when receiving data at only 19200. Adding the -O3 compile option helped in this regard in that I am now rarely seeing packet loss.
Quoted 4 lines
Please also see:
http://www.gossamer-threads.com/lists/linux/kernel/1835761?do=post_view_threaded#1835761
Ironically, combining these might achieve a significant performance improvement over CONFIG_GENERIC_CPU and -O2.
Am 07.03.2014 13:39, schrieb Austin S Hemmelgarn:
Quoted 29 lines · Richard Weinberger
Quoted 28 lines
Quoted 25 lines · Jon Ringle
Quoted 7 lines · Greg KH
Quoted 4 lines · Jon Ringle
+config
CC_OPTIMIZE_FOR_SPEED+ bool "Optimze for speed
(-O3)" + help + Enabling this option will pass "-O3"
to gcc + resulting in a larger kernel (but possibly
faster)Are you sure about that? Have you measured it?
I do know that there is an improvement performance-wise for my particular use-case.
My target is an ARM board being built with gcc-4.8.2. My board has on it a sc16is740 that is used as an RS-485 port. The sc16is740 is on the i2c bus, so when an interrupt comes in to indicate that there is data available to be read, I need to get the data over the i2c bus. I do this on a kthread to do this work. The i2c transactions (using i2c-davinci driver) are also interrupt driven. I was seeing a lot of lost packets when receiving data at only 19200. Adding the -O3 compile option helped in this regard in that I am now rarely seeing packet loss.
Quoted 6 lines
Quoted 4 lines
Please also see:
http://www.gossamer-threads.com/lists/linux/kernel/1835761?do=post_view_threaded#1835761Ironically, combining these might achieve a significant performance improvement over
CONFIG_GENERIC_CPUand -O2.
*might*
We still need a sane proof.
Thanks,
//richard
Quoted 36 lines · Richard Weinberger
Am 07.03.2014 13:39, schrieb Austin S Hemmelgarn:
Quoted 33 lines · Richard Weinberger
Quoted 32 lines
Quoted 15 lines · Jon Ringle
Quoted 7 lines · Greg KH
Quoted 4 lines · Jon Ringle
+config
CC_OPTIMIZE_FOR_SPEED+ bool "Optimze for speed
(-O3)" + help + Enabling this option will pass "-O3"
to gcc + resulting in a larger kernel (but possibly
faster)Are you sure about that? Have you measured it?
I do know that there is an improvement performance-wise for my particular use-case.
Quoted 10 lines
My target is an ARM board being built with gcc-4.8.2. My board has on it a sc16is740 that is used as an RS-485 port. The sc16is740 is on the i2c bus, so when an interrupt comes in to indicate that there is data available to be read, I need to get the data over the i2c bus. I do this on a kthread to do this work. The i2c transactions (using i2c-davinci driver) are also interrupt driven. I was seeing a lot of lost packets when receiving data at only 19200. Adding the -O3 compile option helped in this regard in that I am now rarely seeing packet loss.
Please also see:
http://www.gossamer-threads.com/lists/linux/kernel/1835761?do=post_view_threaded#1835761
Quoted 9 lines
Quoted 2 lines
Ironically, combining these might achieve a significant performance improvement over
CONFIG_GENERIC_CPUand -O2.*might*
We still need a sane proof.Thanks,
//richard
I'm not arguing that, I just don't have the time to test it at the moment; and, "performance improvement" also can mean different things to different people (a lot of RT folks for example don't care if things run faster if it makes them much less deterministic).
Quoted 4 lines · Austin S Hemmelgarn
I'm not arguing that, I just don't have the time to test it at the moment; and, "performance improvement" also can mean different things to different people (a lot of RT folks for example don't care if things run faster if it makes them much less deterministic).
You people never seem to learn: numbers talk, bullshit walks. It is *that* simple.
Signature · 5 lines
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--Quoted 8 lines · Greg KH
init/Kconfig source "usr/Kconfig" · line 1253
Quoted 5 lines · Jon Ringle
init/Kconfig +5
-0+config CC_OPTIMIZE_FOR_SPEED + bool "Optimze for speed (-O3)" + help + Enabling this option will pass "-O3" to gcc + resulting in a larger kernel (but possibly faster)Are you sure about that? Have you measured it?
(Resending this message, since it was "destroyed". Hopefully, this is now an an acceptable form :)
I do know that there is an improvement performance-wise for my particular use-case.
My target is an ARM board being built with gcc-4.8.2. My board has on it a sc16is740 that is used as an RS-485 port. The sc16is740 is on the i2c bus, so when an interrupt comes in to indicate that there is data available to be read, I need to get the data over the i2c bus. I do this on a kthread to do this work. The i2c transactions (using i2c-davinci driver) are also interrupt driven. I was seeing a lot of lost packets when receiving data at only 19200. Adding the -O3 compile option helped in this regard in that I am now rarely seeing packet loss.
Jon
Quoted 17 lines · Jon Ringle
Quoted 8 lines · Greg KH
init/Kconfig source "usr/Kconfig" · line 1253
Quoted 5 lines · Jon Ringle
init/Kconfig +5
-0+config CC_OPTIMIZE_FOR_SPEED + bool "Optimze for speed (-O3)" + help + Enabling this option will pass "-O3" to gcc + resulting in a larger kernel (but possibly faster)Are you sure about that? Have you measured it?
(Resending this message, since it was "destroyed". Hopefully, this is now an an acceptable form :)
I do know that there is an improvement performance-wise for my particular use-case.
Quoted 8 lines
My target is an ARM board being built with gcc-4.8.2. My board has on it a sc16is740 that is used as an RS-485 port. The sc16is740 is on the i2c bus, so when an interrupt comes in to indicate that there is data available to be read, I need to get the data over the i2c bus. I do this on a kthread to do this work. The i2c transactions (using i2c-davinci driver) are also interrupt driven. I was seeing a lot of lost packets when receiving data at only 19200. Adding the -O3 compile option helped in this regard in that I am now rarely seeing packet loss.
I'd take this up with the linux-arm developers, that sounds like something is wrong with your system that a compiler change fixes problems. Something else must be wrong...
good luck,
greg k-h