Re: [patch 3/4] taskstats: Introduce cdata_acct for completecumulative accounting

[Michael Holzheu]

Hello Oleg,

On Tue, 2010-11-23 at 17:59 +0100, Oleg Nesterov wrote: 
> On 11/19, Michael Holzheu wrote:
> > TODO:
> > -----
> > With this patch we take the siglock twice. First for the dead task
> > and second for the parent of the dead task. This give the following
> > lockdep warning (probably a lockdep annotation is needed here):
> 
> And we already discussed this ;) We do not need 2 siglock's, only
> parent's. Just move the callsite in __exit_signal() down, under
> another (lockless) group_dead check.
> 
> Or I missed something?

The problem with moving this down to the second group_dead check is that
after __unhash_process() is called, pid_alive(tsk) which is checked in
thread_group_cputime() returns false. Therefore we always get zero CPU
times.

So I probably have to introduce a second group_dead check at the
beginning of __exit_signal():

@@ -150,6 +153,9 @@ static void __exit_signal(struct task_st
        struct sighand_struct *sighand;
        struct tty_struct *uninitialized_var(tty);

+       if (group_dead)
+               __account_cdata(...);
+
        sighand = rcu_dereference_check(tsk->sighand,
                                        rcu_read_lock_held() ||
                                        
> We can do this before taking ->siglock. Not that I think this really
> matters, but otherwise this looks a bit confusing imho, as if we need
> parent's ->siglock to pin something.

ok

> 
> 
> And thanks for splitting these changes. It was much, much easier to
> read now.

My personal feeling is that probably the only acceptable thing would be
to make the new behavior configurable with a sysctl and define the
default as it currently is (POSIX compliant).

This would only introduce two additional checks in __exit_signal() and
wait_task_zombie() and would not add any new fields to the
signal_struct.

Michael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/