Re: New stacker performance results

From: Valdis.Kletnieks@private
Date: Thu May 26 2005 - 07:13:37 PDT

On Thu, 26 May 2005 01:45:55 EDT, Colin Walters said:
> You could write vtkit_follow_link in i386 assembler too...the question
> is, was the SELinux-based solution actually a bottleneck for system
> performance?

On a 128M (or even 256M - I can feel it on my laptop), it *is* an issue, mostly
due to total memory footprint..

> Ok, this is a more reasonable argument.  Does the strict policy really
> require 17M of kernel memory (that's nonpageable?).  Stephen/James, is
> there a way SELinux memory usage could be reduced for relatively simple
> policies like this?  Besides older machines, once Xen is widely deployed
> it will be valuable to reduce kernel memory usage so that more virtual
> instances can be deployed on the same machine.

% head /proc/slabinfo
slabinfo - version: 2.1 (statistics)
# name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail> : globalstat <listallocs> <maxobjs> <grown> <reaped> <error> <maxfreeable> <nodeallocs> <remotefrees> : cpustat <allochit> <allocmiss> <freehit> <freemiss>
avtab_node        404908 404964     44   84    1 : tunables   32   16    0 : slabdata   4821   4821      0 : globalstat  404912 404912  4821    0                          0    0    0    0 : cpustat 375986  28922      0      0

4,821 4K slab pages.  Just shy of 20M. That's with the Fedora RPM
selinux-policy-strict-1.23.14-2 and only two different user_u defined. The
'targeted' policy is a lot smaller, but you really can't do it easily with the
'targeted' policy because that dumps everything into unconfined_t.  You probably
can heave everything over the side and do up a custom policy that takes
a lot less - but it's *still* going to be more heavyweight.

Which was my point - the fact that you *could* coerce it into an SELinux policy
doesn't mean that it's necessarily the best or most efficient way to solve the

Another issue with doing this in an SELinux-only solution is the maintenance cost
if you want to deploy this alongside current policy - right now, it's a lot harder
to run "strict policy with 3-5 minor changes" than it should be (which is a known
issue, related to "programs/RPMs ship their own incremental policy").

This archive was generated by hypermail 2.1.3 : Thu May 26 2005 - 07:14:50 PDT