[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: HEADS-UP: Stack Smash Protection enabled by default for amd64 and i386
Joerg Sonnenberger wrote:
On Wed, Nov 11, 2009 at 04:55:07PM +0000, Matthias Scheler wrote:
SSP will result in a slowdown of about 5%, please read this thread
for more details:
Just to insert some hard numbers into this thread.
Same for me:
I just finished the generation of the comparison file for libmicro
benchmark against SSP. For those that do not know about libmicro, see .
Pentium M 2GHz (Dothan) (686-class), id 0x6d6
80GiB 5400 RPM IDE disk
4 runs against libmicro:
- 2 runs with full SSP system (USE_SSP=yes),
- 2 runs with a "semi-SSP" system (everything was SSP compiled except
kernel and modules). All runs from a very minimal environment (~ single
user, but with network enabled).
Benchmark are here:
- everything relating to I/O or memory ops (mmap, pipes, sockets, ...)
stay pretty much unaffected by in kernel enabled SSP: sometimes the
NOSSP kernel is faster, sometimes the SSP kernel is. The difference
stays between ~1-2%.
- I can't reproduce the bad results of the cascading flock() calls from
the first run. Probably context specific.
- slower writev(2) calls when writing NULL chars to /dev/null, with
increasing number of iovec structs. Given how short this operation is
expected to be, there could be resolution inconsistencies here.
- pthread creation (pthread_create) seems to become slower under SSP, by
a 10% margin. Reproducible.
- getcontext(2) by a 38% margin, which is quite important. Also
reproducible. Small times, could be exposed to resolution inconsistencies.
I am planning to run more thread-oriented benchmarks.
Main Index |
Thread Index |