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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <[email protected]>
> > >
> > > 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux