Cgroup Learning (6) -- attach task

Attach task

This process corresponds to the process of ECHO 512> tasks operated by the above instance. The essence of this process is to write the tasks file in cgroup first, establish the relationship between the new css_set of the process and all the cgroups that manage it. Then, attach the process based on the attach function of each subsystem. Here we will first introduce the first process and the second process in each subsystem. First look at BT:

12530 (sh) cpu_cgroup_attach call trace: 0xffffffff81065a20 :cpu_cgroup_attach+0x0/0x60 [kernel] 0xffffffff810c1d3e :cgroup_attach_task+0x26e/0x620 [kernel] 0xffffffff810c214c :cgroup_tasks_write+0x5c/0xf0 [kernel] 0xffffffff810be29a :cgroup_file_write+0x2ba/0x320 [kernel] 0xffffffff81177e68 :vfs_write+0xb8/0x1a0 [kernel] 0xffffffff81178871 : sys_write+0x51/0x90[kernel] 0xffffffff8100b0f2 :system_call_fastpath+0x16/0x1b [kernel]

From the BT, we can see that the final function called in the first process is cgroup_attach_task: first, use task_cgroup_from_root to determine which cgroup the task belongs to the hierarchy, A task must belong to a cgroup in hierarchy, and only belongs to one of them. either in the top_cgroup (Task-> cgroups ==& init_css_set) of hierarchy ), or another cgroup in hierarchy:

If (CSS ==& init_css_set) {res = & root-> top_cgroup;} else {struct cg_cgroup_link * link;/* Because css_set is managed by multiple cgroups, however, these cgroups belong to different hierarchy types. Therefore, when traversing a cgroup, its root is equal to the current hierarchy, then this cgroup is the cgroup */list_for_each_entry (link, & CSS-> cg_links, cg_link_list) that the task currently belongs to under the hierarchy {struct cgroup * c = link-> fig; if (c-> root = root) {res = C; break ;}}}

Note: attach must be a process of transferring from an old cgroup to a new cgroup.
If the new cgroup to attach is the same as the cgroup to which the hierarchy belongs before the task, the system returns the result directly. Otherwise, the system first checks whether the task can be can_attach on all subsys, then, use find_css_set to find an existing css_set or create a new one. First, use find_existing_css_set to find whether there is an available css_set (From the css_set_table hash table, find the sub-system that the old css_set of the task belongs to + The css_set linked list that the new sub-system belongs, then, it traverses whether each node in the linked list is the same as the cgroup associated with the old css_set (compare_css_sets, except the new cgroup to attach). The essence is to find whether such a css_set exists: all the cgroups of the old css_set of the task are removed from the cgroup under the current hierarchy, and the newly added cgroup is the css_setOtherwise, create a new css_set and create a new css_set (RES) with the old css_set (oldcg) before the task) all associated cgroups (in fact, root_count hierarchy, because each hierarchy has a cgroup associated with it, except the previous cgroup, then add the new css_set to the hash table hlist. Finally, call the attach of each subsystem, that is, the second process.

Figure 3 (from the http://blog.chinaunix.net/uid-20543183-id-1930840.html) below shows the three processes we described earlier: Mount, mkdir, attach:

Figure 3 Relationship Between cgroup mount, mkdir, and attach

The fields in the task structure are incorrect. They should be: cgroups and cg_list (in 2.6.32-220 kernel ). It mounts a hierarchy consisting of two subsys. Here we will introduce the mount, mkdir, and attach operations in the cgroup framework. Next we will introduce the subsystem of cgroup.