[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
So here are the rest of the benchmarks I have run so far. I can provide
more detailed results to whoever would like to analyze them; feel free
==== sysbench ====
I ran 2 benchmarks:
- the one benchmarking threads creation/destruction.
- the "OLTP" one (online transaction processing), with mysql as the db
server (I can provide the my.cnf if you want). It simulates a typical
online database workload.
What I can say:
- for low number of threads, the highest loss is 4% (== SSP is 4%
'slower' than NO SSP).
- for high concurrency (100+ threads running), it is more difficult to
distinguish one from the other. There is no clear margin.
Note that my host is a P4M 2GHz (centrino, laptop, i386 only): no SMP,
only one core. Concurrency is not something you would expect with such a
==== pure build.sh distribution ====
4 runs (2 with SSP enabled kernel, 2 without SSP kernel).
Each time, the OBJDIR and DESTDIR were moved away, and the computer
rebooted. No -j used.
no-ssp kernel 6254.48 real 5088.01 user 786.01 sys
no-ssp kernel 6415.72 real 5097.60 user 789.96 sys
ssp kernel 6272.31 real 5094.03 user 791.23 sys
ssp kernel 6181.41 real 5090.63 user 794.36 sys
Like abs@ suggested in a private mail, and like I am planning to do, I
will run the same benchmarks against a pure NO-SSP userland and kernel,
just to draw a baseline.
For reference, the libmicro benchmarks:
IMHO, the 5% penalty is exaggerated. It does not look like to be
systematic, and moreover, subject to context (== not easily
reproducible); I am not sure that SSP overhead is that much significant.
Main Index |
Thread Index |