Don't apply for write lock on tasklist_lock if parent doesn't ptrace other processes
in [Kernel]
|
From: Oleg Nesterov on 22 Jul 2010 05:10 I am not surpized perf blaims tasklist, but I am really surpized this patch adds 10% improvement... On 07/21, Roland McGrath wrote: > > > > @@ -331,6 +331,9 @@ void exit_ptrace(struct task_struct *tra > > > struct task_struct *p, *n; > > > LIST_HEAD(ptrace_dead); > > > > > > + if (list_empty(&tracer->ptraced)) > > > + return; > > > + > > > write_lock_irq(&tasklist_lock); > > > list_for_each_entry_safe(p, n, &tracer->ptraced, ptrace_entry) { > > > if (__ptrace_detach(tracer, p)) > > I think we may have tried that before. Oleg can tell us if it's really > safe vs a race with PTRACE_TRACEME or something like that. Yes, this can race with ptrace_traceme(). Without tasklist_lock in exit_ptrace(), it is possible that ptrace_traceme() starts __ptrace_link() before it sees PF_EXITING, and completes before the result of list_add() is visible to the exiting parent. tasklist acts as a barrier. So, this list_empty() check needs taskslit at least for reading. But, we are going to take it for writing right after exit_ptrace() returns, afaics we can add this fastpatch check for free. Uncompiled/untested. Oleg. kernel/ptrace.c | 10 +++++++--- kernel/exit.c | 3 ++- 2 files changed, 9 insertions(+), 4 deletions(-) --- x/kernel/ptrace.c +++ x/kernel/ptrace.c @@ -324,26 +324,30 @@ int ptrace_detach(struct task_struct *ch } /* - * Detach all tasks we were using ptrace on. + * Detach all tasks we were using ptrace on. Called with tasklist held. */ void exit_ptrace(struct task_struct *tracer) { struct task_struct *p, *n; LIST_HEAD(ptrace_dead); - write_lock_irq(&tasklist_lock); + if (likely(list_empty(&tracer->ptraced))) + return; + list_for_each_entry_safe(p, n, &tracer->ptraced, ptrace_entry) { if (__ptrace_detach(tracer, p)) list_add(&p->ptrace_entry, &ptrace_dead); } - write_unlock_irq(&tasklist_lock); + write_unlock_irq(&tasklist_lock); BUG_ON(!list_empty(&tracer->ptraced)); list_for_each_entry_safe(p, n, &ptrace_dead, ptrace_entry) { list_del_init(&p->ptrace_entry); release_task(p); } + + write_lock_irq(&tasklist_lock); } int ptrace_readdata(struct task_struct *tsk, unsigned long src, char __user *dst, int len) --- x/kernel/exit.c +++ x/kernel/exit.c @@ -771,9 +771,10 @@ static void forget_original_parent(struc struct task_struct *p, *n, *reaper; LIST_HEAD(dead_children); + write_lock_irq(&tasklist_lock); + exit_ptrace(father); - write_lock_irq(&tasklist_lock); reaper = find_new_reaper(father); list_for_each_entry_safe(p, n, &father->children, sibling) { -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Roland McGrath on 22 Jul 2010 15:30 > So, this list_empty() check needs taskslit at least for reading. But, we > are going to take it for writing right after exit_ptrace() returns, afaics > we can add this fastpatch check for free. That looks good to me, but it could use some more scare comments. > /* > - * Detach all tasks we were using ptrace on. > + * Detach all tasks we were using ptrace on. Called with tasklist held. * Called with tasklist held for writing, and returns with it held too. * But note it can release and reacquire the lock. > + write_lock_irq(&tasklist_lock); > + /* * Note that exit_ptrace() might drop tasklist_lock and reacquire it. */ > exit_ptrace(father); > > - write_lock_irq(&tasklist_lock); > reaper = find_new_reaper(father); Thanks, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Oleg Nesterov on 23 Jul 2010 13:40 On 07/23, Zhang, Yanmin wrote: > > On Thu, 2010-07-22 at 11:05 +0200, Oleg Nesterov wrote: > > I am not surpized perf blaims tasklist, but I am really surpized this patch > > adds 10% improvement... > I changed aim7 workfile to focus on fork/exec and other a couple of sub-cases. > And this behavior is clear on 8-socket machines. Thanks... > After applying my patch (although it's incorrect as there is a race with TRACEME), > perf shows write_lock_irq in forget_original_parent consumes less than 40% cpu time on > 8-socket machine. Any chance you can test the patch I sent? It should have the same effect, otherwise there is something interesting. > Is it possible to optimize it to use finer locks instead of the global tasklist_lock? Heh. We must optimize it. But it is not clear when ;) Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Oleg Nesterov on 23 Jul 2010 13:50 On 07/22, Roland McGrath wrote: > > > So, this list_empty() check needs taskslit at least for reading. But, we > > are going to take it for writing right after exit_ptrace() returns, afaics > > we can add this fastpatch check for free. > > That looks good to me, but it could use some more scare comments. Good. Hopfully Zhang can test it to confirm it has the same effect. It should, but I am still wondering about 10% improvement. > > /* > > - * Detach all tasks we were using ptrace on. > > + * Detach all tasks we were using ptrace on. Called with tasklist held. > > * Called with tasklist held for writing, and returns with it held too. > * But note it can release and reacquire the lock. OK. > > + write_lock_irq(&tasklist_lock); > > + > /* > * Note that exit_ptrace() might drop tasklist_lock and reacquire it. > */ > > exit_ptrace(father); Well, this comment a bit "unfair", please see below. > > - write_lock_irq(&tasklist_lock); > > reaper = find_new_reaper(father); Note that find_new_reaper() can drop/reacquire tasklist too. Perhaps, /* These two might drop and reacquire tasklist_lock */ exit_ptrace(father); reaper = find_new_reaper(father); ... ? Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Oleg Nesterov on 26 Jul 2010 05:00
On 07/26, Zhang, Yanmin wrote: > > On Fri, 2010-07-23 at 19:34 +0200, Oleg Nesterov wrote: > > On 07/23, Zhang, Yanmin wrote: > > > > > > After applying my patch (although it's incorrect as there is a race with TRACEME), > > > perf shows write_lock_irq in forget_original_parent consumes less than 40% cpu time on > > > 8-socket machine. > > > > Any chance you can test the patch I sent? It should have the same effect, > > otherwise there is something interesting. > 1) with my patch, we got about 13% improvement; > 2) With your patch, we got about 11% improvement; > > Performance is very sensitive to spinlock contention on large machines. Zhang, thank you very much. But. In this case I do not trust these results or I missed something. I mean, they do not look 100% accurate. With your patch: forget_original_parent: exit_ptrace: if (list_empty(ptraced)) return; write_lock_irq(tasklist); ... do a lot more work ... With my patch: forget_original_parent: write_lock_irq(tasklist); exit_ptrace: if (list_empty(ptraced)) return; ... do a lot more work ... The only difference is that we are doing the function call + list_empty() under tasklist, just a few instructions compared to "do a lot more work" in forget_original_parent(). How this can make the 2% difference ? This looks like a noise to me, or do you think I missed something? > > Heh. We must optimize it. But it is not clear when ;) > Thanks. It's better to remove the big lock. Yes. The only problem this is very much nontrival with the current code. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |