[Devel] Re: [RFC][PATCH 2/3] cgroups: subsystem module interface
Paul Menage
menage at google.com
Wed Nov 4 13:18:34 PST 2009
On Wed, Nov 4, 2009 at 12:30 PM, Ben Blum <bblum at andrew.cmu.edu> wrote:
>> + init_cgroup_css(css, ss, dummytop);
>> + init_css_set.subsys[ss->subsys_id] = dummytop->subsys[ss->subsys_id];
>
> There is a problem here; namely, the init_css_set is supposed to be
> immutable after boot. Putting a new subsystem state in it seems like it
> will be impossible to get right, since a hierarchy might be mounted and
> already using the init_css_set. Perhaps it would be better to use
> find_css_set for this?
Hmm, it's not just init_css_set that needs to get a pointer to the new
css, it's all existing css_sets - since every task has to start off in
the root cgroup for the new subsystem. A css_set is just a flattened
cache of the css pointers from all the cgroups that a task is a member
of, so when we add a css pointer to the unmount cgroup, we need to
either update all css_set objects, or else run through every task in
the system and update its cgroups pointer to a new css_set that's
equivalent to its old css_set plus the new css pointer.
Given the races inherent in trying to find and update all tasks in the
system, I think the cleanest way to solve this is:
- copy the css_set_table hash table and clear the original table.
- for each bucket in the hash table:
- for each css_set in the bucket:
- add the new root css to the css_set
- rehash the css_set into the hash table
Unfortunately this issue also makes it a bit harder to support
modular-subsystem unloading.
Paul
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list