Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1610914
| From | Dietmar Eggemann <dietmar.eggemann@arm.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC PATCH 2/5] sched/events: Introduce cfs_rq load tracking trace event |
| Date | 2017-03-28 15:40 +0200 |
| Message-ID | <tpZvR-8gn-61@gated-at.bofh.it> (permalink) |
| References | <tpSXo-3CJ-11@gated-at.bofh.it> <tpSXo-3CJ-9@gated-at.bofh.it> <tpUcO-4ow-15@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 03/28/2017 09:56 AM, Peter Zijlstra wrote:
> On Tue, Mar 28, 2017 at 07:35:38AM +0100, Dietmar Eggemann wrote:
[...]
>> (1) a root task_group:
>>
>> cpu=4 path=/ id=1 load=6 util=331
>
> What's @id and why do we care?
It's a per cgroup/subsystem unique id for every task_group (cpu controller):
struct task_group {
struct cgroup_subsys_state css {
...
int id;
...
}
...
}
The root task group path=/ has id=1 and all autogroups have id=0.
I agree, this id is redundant in case we have the task_group path.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[RFC PATCH 2/5] sched/events: Introduce cfs_rq load tracking trace event Dietmar Eggemann <dietmar.eggemann@arm.com> - 2017-03-28 08:40 +0200
Re: [RFC PATCH 2/5] sched/events: Introduce cfs_rq load tracking trace event Peter Zijlstra <peterz@infradead.org> - 2017-03-28 10:00 +0200
Re: [RFC PATCH 2/5] sched/events: Introduce cfs_rq load tracking trace event Dietmar Eggemann <dietmar.eggemann@arm.com> - 2017-03-28 15:40 +0200
Re: [RFC PATCH 2/5] sched/events: Introduce cfs_rq load tracking trace event Peter Zijlstra <peterz@infradead.org> - 2017-03-28 10:10 +0200
Re: [RFC PATCH 2/5] sched/events: Introduce cfs_rq load tracking trace event Steven Rostedt <rostedt@goodmis.org> - 2017-03-28 16:50 +0200
Re: [RFC PATCH 2/5] sched/events: Introduce cfs_rq load tracking trace event Steven Rostedt <rostedt@goodmis.org> - 2017-03-28 16:50 +0200
Re: [RFC PATCH 2/5] sched/events: Introduce cfs_rq load tracking trace event Peter Zijlstra <peterz@infradead.org> - 2017-03-28 18:50 +0200
Re: [RFC PATCH 2/5] sched/events: Introduce cfs_rq load tracking trace event Peter Zijlstra <peterz@infradead.org> - 2017-03-28 19:10 +0200
Re: [RFC PATCH 2/5] sched/events: Introduce cfs_rq load tracking trace event Patrick Bellasi <patrick.bellasi@arm.com> - 2017-03-28 19:30 +0200
Re: [RFC PATCH 2/5] sched/events: Introduce cfs_rq load tracking trace event Peter Zijlstra <peterz@infradead.org> - 2017-03-28 20:20 +0200
Re: [RFC PATCH 2/5] sched/events: Introduce cfs_rq load tracking trace event Steven Rostedt <rostedt@goodmis.org> - 2017-03-28 19:50 +0200
Re: [RFC PATCH 2/5] sched/events: Introduce cfs_rq load tracking trace event Steven Rostedt <rostedt@goodmis.org> - 2017-03-28 19:50 +0200
Re: [RFC PATCH 2/5] sched/events: Introduce cfs_rq load tracking trace event Dietmar Eggemann <dietmar.eggemann@arm.com> - 2017-03-29 22:50 +0200
Re: [RFC PATCH 2/5] sched/events: Introduce cfs_rq load tracking trace event Dietmar Eggemann <dietmar.eggemann@arm.com> - 2017-03-29 23:10 +0200
Re: [RFC PATCH 2/5] sched/events: Introduce cfs_rq load tracking trace event Peter Zijlstra <peterz@infradead.org> - 2017-03-30 09:10 +0200
Re: [RFC PATCH 2/5] sched/events: Introduce cfs_rq load tracking trace event Dietmar Eggemann <dietmar.eggemann@arm.com> - 2017-03-30 09:50 +0200
csiph-web