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: http://marc.info/?l=linux-fsdevel&m=129591574123544&w=2 and we get a better throughput than 2.6.37 Thanks, Shaohua -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
