From: Daniel J Walsh <dwalsh@redhat.com>
To: William Roberts <bill.c.roberts@gmail.com>
Cc: Ole Kliemann <ole@plastictree.net>, selinux@tycho.nsa.gov
Subject: Re: SELinux performance depending on type count
Date: Tue, 07 Aug 2012 13:36:06 -0400 [thread overview]
Message-ID: <50215206.6060504@redhat.com> (raw)
In-Reply-To: <CAFftDdq9JhRXMTDP4ZSsDOhpUAb5vDAAKPmNJ3Zf_KaeBRzxYw@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/07/2012 01:07 PM, William Roberts wrote:
> Well as far as caching goes, their are cache misses, so as the amount of
> data increase and your cache size stays fixed, they may be an issue...
>
> On Tue, Aug 7, 2012 at 6:02 AM, Ole Kliemann <ole@plastictree.net> wrote:
>> I read on some locations (Fedora FAQ...) that there is an overall
>> performance impact of about 7% when running with SELinux.
>>
>> Does anyone know if this impact is dependent upon the number of types the
>> policy has? I would assume no: A lot of types only take up memory and
>> caching should prevent any impact on the runtime performance.
>>
>> But if there was a performance problem with a lot of types, at what
>> number n would it start to hit hard? And how does it increase (linear,
>> quadratic...)?
>>
>> And would it be better performance-wise to run a MCS-policy with say
>> categories c0.cn than to have types c0_t, ... cn_t?
>>
>> Ole
>
>
>
Also 7% is ridiculously high. I would do your own measuring of SELinux and I
think for most work loads it is lot closer to unmeasurable difference.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlAhUgYACgkQrlYvE4MpobMzcACdEccYKiyfZVeTQYF/06aKwc7i
tU4An1JeSEo6qcfNsIBzeZBn01fLN8KM
=Z4gW
-----END PGP SIGNATURE-----
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
next prev parent reply other threads:[~2012-08-07 17:36 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-07 13:02 SELinux performance depending on type count Ole Kliemann
2012-08-07 14:12 ` David Quigley
2012-08-07 17:07 ` William Roberts
2012-08-07 17:36 ` Daniel J Walsh [this message]
2012-08-08 20:44 ` Ole Kliemann
2012-08-09 10:45 ` Adam Tkac
2012-08-09 11:56 ` Ole Kliemann
2012-08-10 12:11 ` Ole Kliemann
2012-08-10 13:00 ` Stephen Smalley
2012-08-10 14:36 ` Ole Kliemann
2012-08-10 15:05 ` Stephen Smalley
2012-08-10 15:43 ` Ole Kliemann
2012-08-10 15:44 ` Ole Kliemann
2012-08-10 16:08 ` Stephen Smalley
2012-08-10 16:18 ` Stephen Smalley
2012-08-10 17:00 ` Ole Kliemann
2012-08-10 18:08 ` Stephen Smalley
2012-08-10 18:46 ` Ole Kliemann
2012-08-10 18:55 ` Stephen Smalley
2012-08-10 19:11 ` Ole Kliemann
2012-08-10 19:19 ` Stephen Smalley
2012-08-10 19:26 ` Ole Kliemann
2012-08-10 19:50 ` Stephen Smalley
2012-08-10 21:38 ` Ole Kliemann
2012-08-13 12:35 ` Stephen Smalley
2012-08-27 15:28 ` Ole Kliemann
2012-08-27 16:24 ` Stephen Smalley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50215206.6060504@redhat.com \
--to=dwalsh@redhat.com \
--cc=bill.c.roberts@gmail.com \
--cc=ole@plastictree.net \
--cc=selinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.