From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Cc: Oleg Nesterov <oleg@redhat.com>,
Shailabh Nagar <nagar1234@in.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
John stultz <johnstul@us.ibm.com>,
Thomas Gleixner <tglx@linutronix.de>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Roland McGrath <roland@redhat.com>,
Valdis.Kletnieks@vt.edu, linux-kernel@vger.kernel.org,
linux-s390@vger.kernel.org
Subject: Re: [patch v2 4/4] taskstats: Export "cdata_wait" CPU times with taskstats
Date: Mon, 6 Dec 2010 14:36:54 +0530 [thread overview]
Message-ID: <20101206090654.GC3158@balbir.in.ibm.com> (raw)
In-Reply-To: <1291307641.1928.125.camel@holzheu-laptop>
* Michael Holzheu <holzheu@linux.vnet.ibm.com> [2010-12-02 17:34:01]:
> On Wed, 2010-12-01 at 19:51 +0100, Oleg Nesterov wrote:
> > But in fact I don't really understand this anyway. This is called
> > before we reparent our children. This means that ac_cutime/ac_cstime
> > can be changed after that (multithreading, or full_cdata_enabled).
> >
> > Say, taskstats_exit()->fill_stats()->bacct_add_tsk(). Every thread
> > does this, including the group_leader. But, it is possible that
> > group_leader exits first, before other threads. IOW, what
> > stats->ac_cXtime actually mean?
>
> Because I worked mostly with the ptop tool, I was not so much focused on
> the taskstats exit events, but instead more on the taskstats commands to
> query data for running tasks.
>
> For the query scenario stats->ac_cXtime means:
>
> 1) full_cdata=0: "Sum of CPU time of exited child processes where
> sys_wait() have been done (up to this time)"
> 2) full_cdata=1: "Sum of CPU time of exited child processes where
> sys_wait() have been done plus exited child processes where
> the parents ignored SIGCHLD or have set SA_NOCLDWAIT (up to
> this time)"
>
> Regarding taskstats_exit(): Do you have something like the following
> scenario in mind?
>
> 1) You have a thread group with several threads
> 2) Thread group leader dies and reports cdata_wait in taskstats_exit()
> 3) Thread group leader stays around as zombie until the thread
> group dies
> 4) Other forked processes of this thread group die
> 5) cdata_wait of thread group is increased
> 6) The new cdata is not reported by any exit event of the thread group
>
> So maybe we should remove the thread_group_leader() check and report
> cdata_wait for all threads and not only for the thread group leader? We
> also should add ac_tgid to taskstats so that userspace can find the
> corresponding thread group for each thread.
>
> When the last thread exits and the process/thread group dies,
> taskstats_exit() sends an additional taskstats struct to userspace that
> aggregates the thread accounting data. Currently only the delay
> accounting data is aggregated (see
> taskstats_exit->fill_tgid_exit->delayacct_add_tsk). Not sure, why the
> other information is not aggregated. We perhaps also should include
> ac_cXtime in the aggregated taskstats.
>
The delay accounting data is aggregated, the other part tsacct do not
care much about aggregation (IIRC). tsacct was added to export pid
data and never tgid data again IIRC. This subsystem is the one that
owns ac_*, perhaps if tsacct supported tgid's then what you say makes
sense.
--
Three Cheers,
Balbir
next prev parent reply other threads:[~2010-12-06 9:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-29 16:42 [patch v2 0/4] taskstats: Improve cumulative time accounting Michael Holzheu
2010-11-29 16:42 ` [patch v2 1/4] taskstats: Introduce "struct cdata" Michael Holzheu
2010-11-29 16:42 ` [patch v2 2/4] taskstats: Introduce __account_cdata() function Michael Holzheu
2010-11-29 16:42 ` [patch v2 3/4] taskstats: Introduce kernel.full_cdata sysctl Michael Holzheu
2010-11-29 16:42 ` [patch v2 4/4] taskstats: Export "cdata_wait" CPU times with taskstats Michael Holzheu
2010-12-01 18:51 ` Oleg Nesterov
2010-12-02 16:34 ` Michael Holzheu
2010-12-06 9:06 ` Balbir Singh [this message]
2010-12-08 20:23 ` Oleg Nesterov
2010-12-10 13:26 ` Michael Holzheu
[not found] ` <20101211173931.GA8084@redhat.com>
2010-12-13 13:05 ` Michael Holzheu
2010-12-13 13:20 ` Michael Holzheu
2010-12-13 14:33 ` Oleg Nesterov
2010-12-13 16:42 ` Michael Holzheu
2010-12-03 7:33 ` Balbir Singh
2010-12-06 12:37 ` Michael Holzheu
2010-12-06 15:15 ` Balbir Singh
2010-12-07 10:45 ` Michael Holzheu
2010-12-08 20:39 ` Oleg Nesterov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101206090654.GC3158@balbir.in.ibm.com \
--to=balbir@linux.vnet.ibm.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=heiko.carstens@de.ibm.com \
--cc=holzheu@linux.vnet.ibm.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=nagar1234@in.ibm.com \
--cc=oleg@redhat.com \
--cc=roland@redhat.com \
--cc=schwidefsky@de.ibm.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®