lkml.org 
[lkml]   [2011]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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


\
 
 \ /
  Last update: 2011-09-01 00:39    [W:0.203 / U:0.656 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site