On 10/15, Michael Holzheu wrote: > > On Thu, 2010-10-14 at 15:47 +0200, Oleg Nesterov wrote: > > > Yes. But __account_to_parent() always sets p->exit_accounting_done = 1. > > And __exit_signal() calls __account_to_parent() only if it is not set. > > > > This means that we update either cdata_wait (if the child was reaped > > by parent) or cdata_acct (the process auto-reaps itself). > > No. The accounting of cdata_acct is done unconditionally in > __account_to_parent(). It is done for both cases wait=0 and wait=1, > therefore no CPU time gets lost. Accounting of cdata_wait is done only > on the sys_wait() path, where "wait" is "1". Ah, got it, I didn't notice this detail. Thanks. > I think it works as it currently is. But as already said, this probably > could be done better. At least your confusion seems to prove that :-) Perhaps ;) To me, it would be cleaner and simpler if you kill ->exit_accounting_done. Both wait_task_zombie() and __exit_signal() could just call __account_to_parent(parent_for_accounting) unconditionally passing either real_parent or acct_parent as an argument. This also saves a word in task_struct. > de_thread() is also a very interesting spot for accounting. The thread > that calls exec() gets a bit of the identity of the old thread group > leader e.g. PID and start time, but it keeps the old CPU times. This > looks strange to me. Well, the main thread represents the whole process for ps/etc, that is why we update ->start_time. But, > Wouldn't it be better to either exchange the accounting data between old > and new leader I dunno. The exiting old leader will update sig->utime/etc, so we do not lose this info from the "whole process" pov. But yes, if user-space looks at the single thread with that TGID it can notice that, say, utime goes backward. > or add the current accounting data of the new leader to > the signal struct and initialize them with zero again? Sorry, I don't understand this "initialize them with zero". What is "them" ? > > I think you can simplify this, but I am not sure right now. > > > > First of all, ->acct_parent should be moved from task_struct to > > signal_struct. No need to initialize t->acct_parent unless t is > > the group leader (this means we can avoid do/while_each_thread > > loop during re-parenting, but de_thread needs another trivial > > change). > > No need to change forget_original_parent() at all, instead we > > can the single line > > > > p->signal->acct_parent = father->signal->acct_parent; > > > > to reparent_leader(), after the "if (same_thread_group())" check. > > > > What do you think? > > I think it is not that easy because we still have to maintain the > children_acct list. This list is used to reparent all the accounting > children to the new accounting parent. Yes, sure, reparent_leader() should also do list_move_tail(acct_sibling), I forget to mention this. I guess you already understand this, but just in case. Please look at sibling/children relationship. We do not add the sub-threads on ->children list, only the main thread. However, every thread has its own ->parent and ->children, this is because we have __WNOTHREAD. But acct-parenting doesn't have this problem, only the main thread needs the properly initialized ->acct_parent, it is never needed until the whole process dies. > But in principle you are right that acct_parent could be moved to the > signal_struct because we only have to change it, when a thread group > leader dies. Yes. And if we move it into signal_struct, then we shouldn't worry about updating it in de_thread(). However, de_thread() should do list_replace_init(leader->acct_sibling) to add the new leader to acct_children. I am not sure this really makes sense, but in fact you can move ->acct_sibling and ->acct_childen from task_struct to signal_struct as well, note that you can trivially find the group leader looking at signal->leader_pid. (actually, ->group_leader should be moved to signal_struct, but this is another story). In this case de_thread() needs no changes, and we save the space in task_struct. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
