From: Glauber Costa <glommer@parallels.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Balbir Singh <bsingharora@gmail.com>,
<linux-kernel@vger.kernel.org>, <paul@paulmenage.org>,
<lizf@cn.fujitsu.com>, <daniel.lezcano@free.fr>,
<jbottomley@parallels.com>
Subject: Re: [RFD 3/9] Display /proc/stat information per cgroup
Date: Wed, 28 Sep 2011 12:22:58 -0300 [thread overview]
Message-ID: <4E833BD2.2080202@parallels.com> (raw)
In-Reply-To: <1317162107.21836.35.camel@twins>
On 09/27/2011 07:21 PM, Peter Zijlstra wrote:
> On Tue, 2011-09-27 at 15:42 -0300, Glauber Costa wrote:
>>>> +static inline void task_cgroup_account_field(struct task_struct *p,
>>>> + cputime64_t tmp, int index)
>>>> +{
>>>> + struct kernel_stat *kstat;
>>>> + struct task_group *tg = task_group(p);
>>>> +
>>>> + do {
>>>> + kstat = this_cpu_ptr(tg->cpustat);
>>>> + kstat->cpustat[index] = cputime64_add(kstat->cpustat[index],
>>>> + tmp);
>>>> + tg = tg->parent;
>>>> + } while (tg);
>>>> +}
>>>
>>> What protects the walk (tg = tg->parent)? Could you please document it
>> I think that the fact that the hierarchy only grows down, thus parent
>> never changes (or am I wrong?)
>>
>> And since we run all this with preempt disabled and with the runqueue
>> locked, we should have no problems.
>>
>> Do you agree?
>
> Right, so the tg can't be destroyed unless its empty, us finding this
> task in it means its not empty, we require rq->lock or p->pi_lock to
> move the task.
>
> However, afaict we don't actually have any of those locks.
>
> That said, it should be sufficient to wrap the whole thing in
> rcu_read_lock(), accounting one tick funny because a cgroup move race
> isn't the end of the world and its really no different than moving the
> task a little later anyway.
>
> task_group() should complain about this if you compile a kernel with
> CONFIG_PROVE_RCU.
Yeah, wrapping it around rcu_read_lock locks fine.
next prev parent reply other threads:[~2011-09-28 15:24 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-23 22:20 [RFD 0/9] per-cgroup /proc/stat statistics Glauber Costa
2011-09-23 22:20 ` [RFD 1/9] Change cpustat fields to an array Glauber Costa
2011-09-27 21:00 ` Peter Zijlstra
2011-09-28 15:13 ` Glauber Costa
2011-09-28 15:23 ` Peter Zijlstra
2011-09-28 18:19 ` Glauber Costa
2011-09-28 19:09 ` Peter Zijlstra
2011-09-28 20:04 ` Glauber Costa
2011-10-01 17:47 ` Glauber Costa
2011-09-27 21:03 ` Peter Zijlstra
2011-09-28 15:14 ` Glauber Costa
2011-09-23 22:20 ` [RFD 2/9] Move /proc/stat logic inside sched.c Glauber Costa
2011-09-23 22:20 ` [RFD 3/9] Display /proc/stat information per cgroup Glauber Costa
2011-09-27 17:01 ` Balbir Singh
2011-09-27 18:42 ` Glauber Costa
2011-09-27 22:21 ` Peter Zijlstra
2011-09-28 15:22 ` Glauber Costa [this message]
2011-09-28 15:23 ` Glauber Costa
2011-09-27 21:48 ` Peter Zijlstra
2011-09-28 15:14 ` Glauber Costa
2011-09-27 21:52 ` Peter Zijlstra
2011-09-28 15:15 ` Glauber Costa
2011-09-23 22:20 ` [RFD 4/9] Make total_forks per-cgroup Glauber Costa
2011-09-27 22:00 ` Peter Zijlstra
2011-09-28 8:13 ` Martin Schwidefsky
2011-09-28 10:35 ` Peter Zijlstra
2011-09-28 12:42 ` Martin Schwidefsky
2011-09-28 12:53 ` Peter Zijlstra
2011-09-28 15:29 ` Glauber Costa
2011-09-28 15:33 ` Peter Zijlstra
2011-09-28 15:35 ` Glauber Costa
2011-09-28 15:37 ` Peter Zijlstra
2011-09-28 15:39 ` Glauber Costa
2011-09-28 15:28 ` Glauber Costa
2011-09-28 15:27 ` Glauber Costa
2011-09-28 15:26 ` Glauber Costa
2011-09-23 22:20 ` [RFD 5/9] per-cgroup boot time Glauber Costa
2011-09-23 22:20 ` [RFD 6/9] Report steal time for cgroup Glauber Costa
2011-09-23 22:20 ` [RFD 7/9] provide a version of cpuacct statistics inside cpu cgroup Glauber Costa
2011-09-23 22:20 ` [RFD 8/9] provide a version of cpuusage " Glauber Costa
2011-09-23 22:20 ` [RFD 9/9] Change CPUACCT to default n Glauber Costa
2011-09-27 22:11 ` [RFD 0/9] per-cgroup /proc/stat statistics Peter Zijlstra
2011-09-28 15:21 ` Glauber Costa
2011-09-28 15:27 ` Peter Zijlstra
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=4E833BD2.2080202@parallels.com \
--to=glommer@parallels.com \
--cc=a.p.zijlstra@chello.nl \
--cc=bsingharora@gmail.com \
--cc=daniel.lezcano@free.fr \
--cc=jbottomley@parallels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=paul@paulmenage.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.