[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FC61619.7000300@parallels.com>
Date: Wed, 30 May 2012 16:44:09 +0400
From: Glauber Costa <glommer@...allels.com>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>
CC: Paul Turner <pjt@...gle.com>, <linux-kernel@...r.kernel.org>,
<cgroups@...r.kernel.org>, <devel@...nvz.org>,
Tejun Heo <tj@...nel.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
<handai.szj@...il.com>, <Andrew.Phillips@...x.com>,
Serge Hallyn <serge.hallyn@...onical.com>
Subject: Re: [PATCH v3 5/6] Also record sleep start for a task group
On 05/30/2012 04:44 PM, Peter Zijlstra wrote:
> On Wed, 2012-05-30 at 16:24 +0400, Glauber Costa wrote:
>> sleep_start is not for iowait. This is for idle. And I know no other way
>> to collect idle time per cgroup, other than the time during which it was
>> out of the runqueue.
>>
>> Now what you say about the sleepers don't make that much sense for idle
>> because this information is per-cpu as well.
>>
>> When the se is being dequeued, it means none of its children is running
>> on that runqueue. That's idle.
>
> But does that mean the cgroup is idle? Its impossible to re-construct
> the machine state from this per-cpu data if your definition of
> cgroup-idle is the time when _all_ cpus are idle.
>
It is idle for that runqueue, aka cpu. The cgroup itself is idle when
all cpus are idle. And yes, then you have 2s per sec of idle in a 2-way
system.
That's pretty much how a physical box works as well.
--
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