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