[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101203073303.GS2746@balbir.in.ibm.com>
Date: Fri, 3 Dec 2010 13:03:03 +0530
From: Balbir Singh <balbir@...ux.vnet.ibm.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Michael Holzheu <holzheu@...ux.vnet.ibm.com>,
Shailabh Nagar <nagar1234@...ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
John stultz <johnstul@...ibm.com>,
Thomas Gleixner <tglx@...utronix.de>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
Heiko Carstens <heiko.carstens@...ibm.com>,
Roland McGrath <roland@...hat.com>, Valdis.Kletnieks@...edu,
linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org
Subject: Re: [patch v2 4/4] taskstats: Export "cdata_wait" CPU times with
taskstats
* Oleg Nesterov <oleg@...hat.com> [2010-12-01 19:51:28]:
> On 11/29, Michael Holzheu wrote:
> >
> > * I left the struct signal locking in the patch, because I think
> > that in order to get consistent data this is necessary.
>
> OK, I guess you mean that we want to read utime/stime "atomically",
> and thus we need ->siglock to prevent the race with __exit_signal().
>
> > @@ -30,6 +30,7 @@ void bacct_add_tsk(struct taskstats *sta
> > {
> > const struct cred *tcred;
> > struct timespec uptime, ts;
> > + unsigned long flags;
> > u64 ac_etime;
> >
> > BUILD_BUG_ON(TS_COMM_LEN < TASK_COMM_LEN);
> > @@ -71,6 +72,12 @@ void bacct_add_tsk(struct taskstats *sta
> > stats->ac_majflt = tsk->maj_flt;
> >
> > strncpy(stats->ac_comm, tsk->comm, sizeof(stats->ac_comm));
> > + if (thread_group_leader(tsk) && lock_task_sighand(tsk, &flags)) {
> > + struct cdata *cd = &tsk->signal->cdata_wait;
> > + stats->ac_cutime = cputime_to_usecs(cd->utime);
> > + stats->ac_cstime = cputime_to_usecs(cd->stime);
>
> perhaps we need a small comment to explain ->siglock...
>
> 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?
>
stats->ac_* time was designed only for tgid's to begin with, so I am
not sure if ac_cXtime makes sense for threads
>
> Nevermind, the whole series looks correct to me. Although I still
> can't find the time to read it ;) But at first glance this version
> addresses all concerns we discussed before.
>
> Oleg.
>
--
Three Cheers,
Balbir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists