Announcement

Collapse
No announcement yet.

The Cost of SELinux, Audit, & Kernel Debugging

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • The Cost of SELinux, Audit, & Kernel Debugging

    Phoronix: The Cost of SELinux, Audit, & Kernel Debugging

    When benchmarking development releases of Fedora in particular, they often end up being much slower than the final build and perform lower when compared against some of the other leading desktop distributions. As we have mentioned in previous articles, this is generally due to the debugging support enabled within the development builds of Fedora. To see just what the performance cost is, we have compared the Fedora 11 performance of the normal kernel against the kernel-debug package. Additionally, we also compared the performance when disabling SELinux and system auditing support.

    http://www.phoronix.com/vr.php?view=14104

  • #2
    This is an EXCELLENT benchmark article!!!

    I have always wondered about this.

    It's unfortunate to see that the applications that suffer most from SELinux are the ones that need it the most. Of course they are also the ones that are making the most use of it.

    Comment


    • #3
      I'm working on SELinux at work, and I had been wondering about the cost of SELinux quite a lot.
      Thanks a lot for taking the time to do check it!

      Comment


      • #4
        A truly great article. BTW, is it only me or do other people get a constant double-take with these "fewer are better" measurements, especially as they're thrown in with "bigger is better" randomly? I always go, wtf the debugging symbols improve speed??? And then, oh yeah, it's one of those fewer are better...

        Why don't you do something like this:


        I think this is much more obvious (though it needs a bit more work)

        Comment


        • #5
          Great article!

          Comment


          • #6
            Originally posted by loonyphoenix View Post
            A truly great article. BTW, is it only me or do other people get a constant double-take with these "fewer are better" measurements, especially as they're thrown in with "bigger is better" randomly? I always go, wtf the debugging symbols improve speed??? And then, oh yeah, it's one of those fewer are better...

            Why don't you do something like this:


            I think this is much more obvious (though it needs a bit more work)
            Instead of turning the graph upside down, turn the equation upside down and report transactions/sec.

            Comment


            • #7
              Excellent! Very informative benchmark. It's things like these that make you see the importance of phoronix and why you should subscribe to support them

              Comment


              • #8
                Originally posted by frantaylor View Post
                Instead of turning the graph upside down, turn the equation upside down and report transactions/sec.
                Or to be pedantic, average transactions per second.

                Comment


                • #9
                  Originally posted by nanonyme View Post
                  Or to be pedantic, average transactions per second.
                  It would be nice to see the range of times, too. People who buy databases want to know the worst-case performance, not the average. There are graphs in Tufte's books that illustrate these things nicely.

                  Comment


                  • #10
                    Originally posted by frantaylor View Post
                    It would be nice to see the range of times, too. People who buy databases want to know the worst-case performance, not the average. There are graphs in Tufte's books that illustrate these things nicely.
                    Ah, good point. Maybe display a statistics that has minimum, maximum, median and average of all scores?

                    Comment


                    • #11
                      The 11th Commandment: Thou shalt not create a graph without reading and understanding "The Visual Display of Quantitative Information" by Edward Tufte.

                      Comment


                      • #12
                        the cost of SELinux is not eliminated by just disabling it at boot time. there is a noticable cost to have it compiled into the kernel, even if it's not used. so it would be good to see a different kernel compiled with all the same options except for selinux

                        In addition, all the Fedora binaries involve selinux libraries in userspace, and just linking in these libraries can impact performance (there was an interesting discussion a couple weeks ago on the git mailing list about performance issues with one of the tools, and part of the problem was that on some distros with selinux there were many additional libraries being loaded.

                        unfortunantly testing this with a fully cleaned userspace involves recompiling a lot of the system (potentially including glibc). the only distro that I know of that makes this sort of testing relativly easy is gentoo.

                        Comment


                        • #13
                          Originally posted by dlang View Post
                          unfortunantly testing this with a fully cleaned userspace involves recompiling a lot of the system (potentially including glibc). the only distro that I know of that makes this sort of testing relativly easy is gentoo.
                          Although it's time-consuming even in Gentoo.

                          Comment


                          • #14
                            Originally posted by dlang View Post
                            the cost of SELinux is not eliminated by just disabling it at boot time. there is a noticable cost to have it compiled into the kernel, even if it's not used. so it would be good to see a different kernel compiled with all the same options except for selinux

                            In addition, all the Fedora binaries involve selinux libraries in userspace, and just linking in these libraries can impact performance (there was an interesting discussion a couple weeks ago on the git mailing list about performance issues with one of the tools, and part of the problem was that on some distros with selinux there were many additional libraries being loaded.

                            unfortunantly testing this with a fully cleaned userspace involves recompiling a lot of the system (potentially including glibc). the only distro that I know of that makes this sort of testing relativly easy is gentoo.
                            When you consider the pain and time involved, you'd have to use it for years before it paid off. Look at those graphs, we are talking about a couple of percent. How much is your time worth? Even on a server you would be better off investing in faster hardware to overcome the performance difference.

                            Comment


                            • #15
                              Originally posted by frantaylor View Post
                              When you consider the pain and time involved, you'd have to use it for years before it paid off. Look at those graphs, we are talking about a couple of percent. How much is your time worth? Even on a server you would be better off investing in faster hardware to overcome the performance difference.
                              Plus on a server you would probably actually appreciate the security more than a slight increase of performance.

                              Comment

                              Working...
                              X