On Thu, Jun 21, 2018 at 5:25 PM Huang, Ying wrote:
> Do you have interest in some other comparison?
No, I think the overhead of the strong stackprotector is a bit sad,
but I assume it's because of the nasty code to load the stack canary
from a cacheline that has absolutely nothing else in it.
On Thu, Jun 21, 2018 at 5:25 PM Huang, Ying wrote:
> Do you have interest in some other comparison?
No, I think the overhead of the strong stackprotector is a bit sad,
but I assume it's because of the nasty code to load the stack canary
from a cacheline that has absolutely nothing else in it.
Hi, Linus,
Linus Torvalds writes:
> On Thu, Jun 21, 2018 at 5:10 PM kernel test robot
> wrote:
>>
>> FYI, we noticed a -5.6% regression of netperf.Throughput_total_tps
>> due to commit 050e9b ("Kbuild: rename CC_STACKPROTECTOR[_STRONG]
>> config variables")
>
> That's perhaps a surprisingly
Hi, Linus,
Linus Torvalds writes:
> On Thu, Jun 21, 2018 at 5:10 PM kernel test robot
> wrote:
>>
>> FYI, we noticed a -5.6% regression of netperf.Throughput_total_tps
>> due to commit 050e9b ("Kbuild: rename CC_STACKPROTECTOR[_STRONG]
>> config variables")
>
> That's perhaps a surprisingly
On Thu, Jun 21, 2018 at 5:10 PM kernel test robot wrote:
>
> FYI, we noticed a -5.6% regression of netperf.Throughput_total_tps due to
> commit 050e9b ("Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables")
That's perhaps a surprisingly large cost to stack protector, but you
did move
On Thu, Jun 21, 2018 at 5:10 PM kernel test robot wrote:
>
> FYI, we noticed a -5.6% regression of netperf.Throughput_total_tps due to
> commit 050e9b ("Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables")
That's perhaps a surprisingly large cost to stack protector, but you
did move
6 matches
Mail list logo
