Hi,
one more set of performance results, on a 2-cpu opteron, fc3, with a dummy
selinux policy (it was just what was installed, new systems not yet ready).
Main difference from previous tests is that security_get_value() was
switched from the weird inline to a fastcall function.
Tests were 50 runs of dbench and tbench, and 10 runs of kernbench and
reaim. For reaim, I am at the moment presenting mean max throughput, but
will try to send the gnuplot datafiles for mean throughput vs number of
jobs (1-15 step 2) tomorrow. I'm reporting mean and 95% confidence
interval.
Kernels tested were 2.6.12-rc2 with:
likely: stacker+selinux+capstack with a 'likely' statement thrown
in at security_get_value (to try to speed up the single lsm
using i_security case)
stacker: stacker+selinux+capstack
selinux: selinux+capabilities (no stacker)
noselinux: kernel with capabilities (no stacker or selinux)
stack-noselinux: kernel with stacker+capabilities but no selinux
The fact that stack-noselinux outperforms noselinux shows that stacker
has (at worst, haha :) negligible performance impact. Profiling data
has shown security_get_value to be the main bottleneck. However,
supporting stacker without supporting the sharing of inode->i_security
would be bad for stacking selinux+digsig, selinux+ima, and selinux+
evm/slim (the tpm-based integrity verification modules), as some of these
modules would have to implement their own hash tables to keep the kernel
object security data.
At this point I would like to forward stacker to the lkml for comment.
Please let me know if there are any objections to that.
thanks,
-serge
likely stacker selinux noselinux stack-noselinux
dbench 1197+-13 1195+-15 1230+-11 1365+-13 1371.33+-12
kernbench 29.93+-.11 30.04+-.10 30.65+-.09 28.15+-.13 28.29+-.10
reaim 439467+-8204 447342+-7316 462965+-7975 501477+-8427 518231+-12239
tbench 241.62+-1.86 245.64+-2.59 241.89+-2.82 241.42+-2.74 248.88+-3.94
This archive was generated by hypermail 2.1.3 : Tue Jun 07 2005 - 21:22:43 PDT