Port-i386 archive

[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 [1].

Hardware:
Pentium M 2GHz (Dothan) (686-class), id 0x6d6
1GB RAM
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:

http://www.netbsd.org/~jym/comparison-1.html
http://www.netbsd.org/~jym/comparison-2.html


General:
- 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.

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.

[1] http://pkgsrc.se/wip/libmicro

--
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost



Home | Main Index | Thread Index | Old Index