Re: [PATCH 2/4] coredump: speedup SIGKILL sending

[Oleg Nesterov <oleg@tv-sign.ru>]

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.