audit.82 kernel

[David Woodhouse]

On Sat, 2005-07-30 at 22:50 -0400, Steve Grubb wrote:
> I'm game to do the performance testing. Do you want to make a .83 kernel or 
> just post a patch? 

I'm building audit.83 with this...

--- linux-2.6.9/kernel/auditfs.c~	2005-07-20 15:42:46.000000000 +0100
+++ linux-2.6.9/kernel/auditfs.c	2005-07-31 10:46:06.000000000 +0100
@@ -116,10 +116,17 @@ static struct audit_inode_data *audit_da
 	struct audit_inode_data *ret = NULL;
 	int h;
 
+	/* Short-circuit _without_ getting the lock. Even if i_state is being
+	   modified, it won't affect the I_AUDIT bit, unless the I_AUDIT
+	   bit itself is actually being changed -- which is fine. Either
+	   we tested before or after the change; either is fine. */
+	if (!allocate && !(inode->i_state & I_AUDIT))
+		return NULL;
+
 	spin_lock(&auditfs_hash_lock);
 
-	/* I_AUDIT bit can only be changed under auditfs_hash_lock, so no need
-	   to lock inode_lock (on all known hardware) */
+	/* If we think there are audit data attached, double-check that
+	   now we have the lock */
 	if (!allocate && !(inode->i_state & I_AUDIT))
 		goto out;
 

> >It'll make zero difference in the profile, AFAICT. Let's not just move stuff
> >around for the sake of it. 
> 
> Well, in this profile - you're right. But regarding nested function calls, it 
> does save some time. This function is important, audit_syscall_exit. 
> Everything does it. Lets make it 100% optimal.

Why do you speak of 'nested function calls'? We're talking about moving
two simple assignments which are going to be executed in 99.999% of
cases anyway. 

You'd do better to look at access patterns and re-order the members of
the audit context for optimal cache performance. At the moment, when we
zero 'in_syscall' and 'auditable' that's actually likely to be dirtying
two separate cache lines.

But I don't really want to be doing even that at this stage. We can do
it upstream but now is not the time to be changing anything more than we
really need to in the kernels which are supposed to be in certification
_already_. If the performance testing had started a few months ago, then
perhaps we could have done it before the certification -- but I really
don't think we should be going too far with it right now.

-- 
dwmw2