lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 07 Mar 2014 07:51:56 -0500
From:	Austin S Hemmelgarn <>
To:	Richard Weinberger <>,
	Borislav Petkov <>,
	Jon Ringle <>
CC:	Greg KH <>,
	"Ringle, Jonathan" <>,
	"" <>
Subject: Re: [PATCH] Add option to build with -O3

On 2014-03-07 07:42, Richard Weinberger wrote:
> Am 07.03.2014 13:39, schrieb Austin S Hemmelgarn:
>> On 2014-03-06 08:28, Richard Weinberger wrote:
>>> On Wed, Mar 5, 2014 at 6:37 AM, Jon Ringle <>
>>> wrote:
>>>> On Wed, 5 Mar 2014, Greg KH wrote:
>>>>> On Tue, Mar 04, 2014 at 07:01:49PM -0500, Jon Ringle wrote:
>>>>>> +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.
>>> Please also see: 
>> Ironically, combining these might achieve a significant performance
>> improvement over CONFIG_GENERIC_CPU and -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).
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists