Re: 2.4.x performance tests Re: [PATCH] BUG() in exec_mmap()

[Ernie Petrides]

On Thursday, 9-Oct-2003 at 17:25 -0300, Marcelo Tosatti wrote:

> BTW, further performance testing of the removal of this optimization is
> VERY welcome.
>
> I've done some tests and no big performance harm has showed up, but thats
> just me.


In a variation of a (loosely) 2.4.21-based kernel, I get a 0% degradation
in the speed of a program exec'ing itself 1,000,000 times with the addition
of the missing locking in exec_mmap():

--- linux-2.4.21/fs/exec.c.orig
+++ linux-2.4.21/fs/exec.c
@@ -452,9 +452,11 @@ static int exec_mmap(void)
 
 	old_mm = current->mm;
 	if (old_mm && atomic_read(&old_mm->mm_users) == 1) {
+		down_write(&old_mm->mmap_sem);
 		mm_release();
 		exit_aio(old_mm);
 		exit_mmap(old_mm);
+		up_write(&old_mm->mmap_sem);
 		return 0;
 	}
 

Applying your change to the same kernel, I get a 2.5% degradation in the
same test case:

--- linux-2.4.21/fs/exec.c.orig
+++ linux-2.4.21/fs/exec.c
@@ -451,12 +451,6 @@ static int exec_mmap(void)
 	struct mm_struct * mm, * old_mm;
 
 	old_mm = current->mm;
-	if (old_mm && atomic_read(&old_mm->mm_users) == 1) {
-		mm_release();
-		exit_aio(old_mm);
-		exit_mmap(old_mm);
-		return 0;
-	}
 
 	mm = mm_alloc();
 	if (mm) {


Average times over 3 runs (of 1,000,000 execs each) were:

	base kernel:	529 elapsed seconds
	w/1st change:	529 elapsed seconds
	w/2nd change:	542 elapsed seconds

I wouldn't bother optimizing for an exec() syscall, but the 1st change
also eliminates the possibility of two ENOMEM error paths in the typical
case of not sharing an mm_struct.


Also, a reproducer that could expose the race condition (in typically 5-20
seconds) on a dual-Xeon Dell box ran for 10's of minutes without problems
with either fix.

Cheers.  -ernie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/