Re: Stacker performance results

From: Serge Hallyn (serue@private)
Date: Thu Mar 17 2005 - 06:05:33 PST


On Thu, 2005-03-17 at 08:22 -0500, Stephen Smalley wrote:
> On Wed, 2005-03-16 at 14:55 -0600, Serge Hallyn wrote:
> > Attached are a set of performance results comparing 2.6.11-rc5 under
> > RedHat REL4 on power5 1.5Ghz, 4cpus (smt-enabled=0), 16G RAM, with an
> > ext2 filesystem.  -nostack is a kernel with selinux and capability.
> > stack is a kernel with stacker, selinux, and cap_stack.
> > 
> > dbench (run as dbench -c client_plain.txt 4, three times)
> > nostack:   872.617 882.029 870.968
> > stack:     799.608 798.028 800.122
> > 
> > hackbench (run as ./hackbench 100)
> > nostack:   5.064
> > stack:     6.721
> > 
> > unixbench (full report files are attached)
> > nostack:   494.3
> > stack:     447.1
> 
> Hmmm...I'm surprised at how poorly stacker faired in these benchmarks,

Note that the stock REL4 2.6.9 kernel fares far worse.  Dbench comes in
at

dbench 693.689 697.263

> given the changeover to being lockless for the LSM chains and for the
> stacker.

Once the lmbench runs are done, I will quickly rerun a few of these
tests on a kernel with stacker, but without selinux using the security
blob chaining code, to see just how much overhead that is still adding.

>   Where is the latest version of the code?  The attachment from
> your earlier posting?  Or the sourceforge site?

This is using the sourceforge code.  The tarball in stacking-patches.04
should still be accurate, except for lacking the ppc64 compilation fix.

The attachment I had sent out last time, introducing an hlist per LSM
hook, resulted in worse benchmark performance on both x86 and ppc64,
even though timed kernel compiles were faster on x86 and unchanged on
ppc64.

thanks,
-serge

-- 
Serge Hallyn <serue@private>



This archive was generated by hypermail 2.1.3 : Thu Mar 17 2005 - 06:04:47 PST