Messages in this thread | | | From | Paul Menage <> | Date | Wed, 31 Aug 2011 15:36:05 -0700 | Subject | Re: [RFD] Task counter: cgroup core feature or cgroup subsystem? (was Re: [PATCH 0/8 v3] cgroups: Task counter subsystem) |
| |
On Sat, Aug 27, 2011 at 6:40 AM, Frederic Weisbecker <fweisbec@gmail.com> wrote: > > Whatever we do, we need that lock. So we can pick your > solution that references cgroups that belong to multi-bindable > subsystems for a given task in css_set, or we can have tsk->cgroups->subsys[] > a variable size array that references 1 * singletons and N * multi > bindable subsystems, N beeing the number of hierarchies that use > a given subsystem.
I think that the two approaches give access to the same amount of information, and would need to be constructed and used in approximately the same way.
I think that adding the hierarchy->cgroup mapping as a variable-sized array is simpler conceptually than making the existing fixed-size subsys array be variable sized and shifting whenever a hierarchy is added/removed.
But I think the first approach to try would be:
- make task_cgroup_from_root callable with either the task being locked or cgroup_mutex being held - expose this in some way outside of the cgroups framework - maybe a function that returns an array of cgroups for a task, one for each hierarchy.
This wouldn't involve adding any extra data structures, and we could later make css_set cache more information if it turned out that it needed better performance.
Paul
| |