Messages in this thread | | | Date | Sat, 8 Apr 2006 03:28:38 +0400 | From | Oleg Nesterov <> | Subject | Re: [PATCH 2/4] coredump: speedup SIGKILL sending |
| |
On 04/06, Lee Revell wrote: > On Fri, 2006-04-07 at 03:55 +0400, Oleg Nesterov wrote: > > On 04/06, Lee Revell wrote: > > > On Fri, 2006-04-07 at 02:06 +0400, Oleg Nesterov wrote: > > > > With this patch a thread group is killed atomically under ->siglock. > > > > This is faster because we can use sigaddset() instead of force_sig_info() > > > > and this is used in further patches. > > > > > > > > Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru> > > > > > > Won't this cause huge latencies when a process with lots of threads is > > > killed? > > > > Yes, irqs are disabled. But this is not worse than 'kill -9 pid', note > > that __group_complete_signal() or zap_other_threads() do the same. > > Those have been problematic in the past. I am just wondering if this > will be a latency regression, or if changes elsewhere in your patch > negate the effect.
zap_process() disables irqs while traversing ->thread_group list. So yes, if a process has a lot of threads it will be a latency regression. (but again, __group_complete_signal() does the same while delivering this signal, so I don't think this change can make things worse).
However this allows us to avoid tasklist_lock in zap_threads() so I think it is worth it. Please note that tasklist_lock was held while iterating over _all_ threads in system, not only current's thread group.
Oleg.
- 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/
| |