Messages in this thread Patches in this message | | | Subject | Re: 2.4.x performance tests Re: [PATCH] BUG() in exec_mmap() | Date | Mon, 13 Oct 2003 02:52:44 -0400 | From | 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |