[lkml]   [2011]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Make RCU dcache work with CONFIG_SECURITY=y
    On Fri, 2011-04-22 at 08:23 +0800, Andi Kleen wrote:
    > We found that all .38+ kernels with CONFIG_SECURITY just enables -- but
    > not even any security module active -- are slower than .37. And also
    > they don't really scale on larger machines. CONFIG_SECURITY
    > is a quite common configuration, so this was seen multiple times.
    > The problem is that with CONFIG_SECURITY every directory permission
    > check will drop out of the RCU walk and redo a bunch of work
    > (and not scale of course), just in case the security module
    > cannot handle it.
    > This patchkit tries to address this. First it moves the check for
    > RCU walks into the low level security module, so for the
    > CONFIG_SECURITY=y selinux=0 at runtime case you always get full
    > performance. This is an independent patch.
    > Then it turned out that the two security modules who use the
    > inode_exec_permission hook that impacts dcache walking -- SMACK
    > and selinux -- already use RCU internally. So I added two
    > followon patches that make them not drop out of the RCU walk,
    > as long as they stay in their RCU "fast" path. For selinux
    > this means a cache hit only and no audit event. For smack
    > it means any check as long as auditing is disabled.
    > I didn't find good test suites for the security modules, so
    > there wasn't a lot of testing on this unfortunately
    > (the selinux one for LTP doesn't seem to work). Some close
    > review of these changes is needed.
    > On the other hand the VFS changes itself are very straight forward
    > and the 1/1 patch is very straight forward (and a win in itself)
    > The bottom line is with this patchkit a CONFIG_SECURITY=y
    > kernel has as good VFS performance as a kernel with CONFIG_SECURITY
    > disabled.
    Great! This fully recovers the dbench regression I reported back:
    and we get a better throughput than 2.6.37


     \ /
      Last update: 2011-04-22 03:43    [W:0.029 / U:112.700 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site