[Adding a few more people and the containers to the copy] On Thu, Oct 28, 2010 at 5:44 PM, Tommaso Cucinotta <tommaso.cucinotta@xxxxxxxx> wrote: > Hi, > > I'm trying to get some understanding of the current cgroups in-kernel > implementation > (after having read Documentation/cgroup* and having browsed a bit the code). > To this purpose, I tried to draw the relationships among the involved data > structures > (I'm limited to its relationship with [real-time] scheduling), and obtained > this: > > http://retis.sssup.it/~tommaso/cgroups.odg > http://retis.sssup.it/~tommaso/cgroups.eps > > (You can see in the bottom left part of the diagram a little > "key/legend/pattern" for representing lists). > > I might have done mistakes, however the greatest doubts that I have now > concern the relative > cardinalities of the various associated items. Namely: > a) why doesn't a cgroup object directly point to a css_set one, but to a > list of them (via cg_cgroup_list elements) ? > it seems that a cgroup object may be associated to multiple css_set > objects, which in turn contain vectors of > cgroup_subsys_state; > b) however, cgroup.subsys[] would point to a single cgroup_subsys_state > object per subsys_id, so, what is the > difference between cgroup.subsys[] and css_set.subsys[] ? (or, are these > all redundant pointers and point > to the same cgroup_subsys_state objects ?) > c) is css_set.cg_links used to point to (the head of) a list of > cg_cgroup_link objects, or is it used to link multiple css_set objects into > a list ? In the latter case, where is the head of the list pointed to from ? > > Apologies for the newbie questions that I might have posted; FYI, I'm trying > to set-up RT scheduling groups without using the VFS-based cgroups > interface. > > Thanks in advance, regards (please, reply in cc to my e-mail address). > > Tommaso > > -- _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
