Root/
1 | CGROUPS |
2 | ------- |
3 | |
4 | Written by Paul Menage <menage@google.com> based on |
5 | Documentation/cgroups/cpusets.txt |
6 | |
7 | Original copyright statements from cpusets.txt: |
8 | Portions Copyright (C) 2004 BULL SA. |
9 | Portions Copyright (c) 2004-2006 Silicon Graphics, Inc. |
10 | Modified by Paul Jackson <pj@sgi.com> |
11 | Modified by Christoph Lameter <clameter@sgi.com> |
12 | |
13 | CONTENTS: |
14 | ========= |
15 | |
16 | 1. Control Groups |
17 | 1.1 What are cgroups ? |
18 | 1.2 Why are cgroups needed ? |
19 | 1.3 How are cgroups implemented ? |
20 | 1.4 What does notify_on_release do ? |
21 | 1.5 How do I use cgroups ? |
22 | 2. Usage Examples and Syntax |
23 | 2.1 Basic Usage |
24 | 2.2 Attaching processes |
25 | 2.3 Mounting hierarchies by name |
26 | 2.4 Notification API |
27 | 3. Kernel API |
28 | 3.1 Overview |
29 | 3.2 Synchronization |
30 | 3.3 Subsystem API |
31 | 4. Questions |
32 | |
33 | 1. Control Groups |
34 | ================= |
35 | |
36 | 1.1 What are cgroups ? |
37 | ---------------------- |
38 | |
39 | Control Groups provide a mechanism for aggregating/partitioning sets of |
40 | tasks, and all their future children, into hierarchical groups with |
41 | specialized behaviour. |
42 | |
43 | Definitions: |
44 | |
45 | A *cgroup* associates a set of tasks with a set of parameters for one |
46 | or more subsystems. |
47 | |
48 | A *subsystem* is a module that makes use of the task grouping |
49 | facilities provided by cgroups to treat groups of tasks in |
50 | particular ways. A subsystem is typically a "resource controller" that |
51 | schedules a resource or applies per-cgroup limits, but it may be |
52 | anything that wants to act on a group of processes, e.g. a |
53 | virtualization subsystem. |
54 | |
55 | A *hierarchy* is a set of cgroups arranged in a tree, such that |
56 | every task in the system is in exactly one of the cgroups in the |
57 | hierarchy, and a set of subsystems; each subsystem has system-specific |
58 | state attached to each cgroup in the hierarchy. Each hierarchy has |
59 | an instance of the cgroup virtual filesystem associated with it. |
60 | |
61 | At any one time there may be multiple active hierarchies of task |
62 | cgroups. Each hierarchy is a partition of all tasks in the system. |
63 | |
64 | User level code may create and destroy cgroups by name in an |
65 | instance of the cgroup virtual file system, specify and query to |
66 | which cgroup a task is assigned, and list the task pids assigned to |
67 | a cgroup. Those creations and assignments only affect the hierarchy |
68 | associated with that instance of the cgroup file system. |
69 | |
70 | On their own, the only use for cgroups is for simple job |
71 | tracking. The intention is that other subsystems hook into the generic |
72 | cgroup support to provide new attributes for cgroups, such as |
73 | accounting/limiting the resources which processes in a cgroup can |
74 | access. For example, cpusets (see Documentation/cgroups/cpusets.txt) allows |
75 | you to associate a set of CPUs and a set of memory nodes with the |
76 | tasks in each cgroup. |
77 | |
78 | 1.2 Why are cgroups needed ? |
79 | ---------------------------- |
80 | |
81 | There are multiple efforts to provide process aggregations in the |
82 | Linux kernel, mainly for resource tracking purposes. Such efforts |
83 | include cpusets, CKRM/ResGroups, UserBeanCounters, and virtual server |
84 | namespaces. These all require the basic notion of a |
85 | grouping/partitioning of processes, with newly forked processes ending |
86 | in the same group (cgroup) as their parent process. |
87 | |
88 | The kernel cgroup patch provides the minimum essential kernel |
89 | mechanisms required to efficiently implement such groups. It has |
90 | minimal impact on the system fast paths, and provides hooks for |
91 | specific subsystems such as cpusets to provide additional behaviour as |
92 | desired. |
93 | |
94 | Multiple hierarchy support is provided to allow for situations where |
95 | the division of tasks into cgroups is distinctly different for |
96 | different subsystems - having parallel hierarchies allows each |
97 | hierarchy to be a natural division of tasks, without having to handle |
98 | complex combinations of tasks that would be present if several |
99 | unrelated subsystems needed to be forced into the same tree of |
100 | cgroups. |
101 | |
102 | At one extreme, each resource controller or subsystem could be in a |
103 | separate hierarchy; at the other extreme, all subsystems |
104 | would be attached to the same hierarchy. |
105 | |
106 | As an example of a scenario (originally proposed by vatsa@in.ibm.com) |
107 | that can benefit from multiple hierarchies, consider a large |
108 | university server with various users - students, professors, system |
109 | tasks etc. The resource planning for this server could be along the |
110 | following lines: |
111 | |
112 | CPU : Top cpuset |
113 | / \ |
114 | CPUSet1 CPUSet2 |
115 | | | |
116 | (Profs) (Students) |
117 | |
118 | In addition (system tasks) are attached to topcpuset (so |
119 | that they can run anywhere) with a limit of 20% |
120 | |
121 | Memory : Professors (50%), students (30%), system (20%) |
122 | |
123 | Disk : Prof (50%), students (30%), system (20%) |
124 | |
125 | Network : WWW browsing (20%), Network File System (60%), others (20%) |
126 | / \ |
127 | Prof (15%) students (5%) |
128 | |
129 | Browsers like Firefox/Lynx go into the WWW network class, while (k)nfsd go |
130 | into NFS network class. |
131 | |
132 | At the same time Firefox/Lynx will share an appropriate CPU/Memory class |
133 | depending on who launched it (prof/student). |
134 | |
135 | With the ability to classify tasks differently for different resources |
136 | (by putting those resource subsystems in different hierarchies) then |
137 | the admin can easily set up a script which receives exec notifications |
138 | and depending on who is launching the browser he can |
139 | |
140 | # echo browser_pid > /mnt/<restype>/<userclass>/tasks |
141 | |
142 | With only a single hierarchy, he now would potentially have to create |
143 | a separate cgroup for every browser launched and associate it with |
144 | approp network and other resource class. This may lead to |
145 | proliferation of such cgroups. |
146 | |
147 | Also lets say that the administrator would like to give enhanced network |
148 | access temporarily to a student's browser (since it is night and the user |
149 | wants to do online gaming :)) OR give one of the students simulation |
150 | apps enhanced CPU power, |
151 | |
152 | With ability to write pids directly to resource classes, it's just a |
153 | matter of : |
154 | |
155 | # echo pid > /mnt/network/<new_class>/tasks |
156 | (after some time) |
157 | # echo pid > /mnt/network/<orig_class>/tasks |
158 | |
159 | Without this ability, he would have to split the cgroup into |
160 | multiple separate ones and then associate the new cgroups with the |
161 | new resource classes. |
162 | |
163 | |
164 | |
165 | 1.3 How are cgroups implemented ? |
166 | --------------------------------- |
167 | |
168 | Control Groups extends the kernel as follows: |
169 | |
170 | - Each task in the system has a reference-counted pointer to a |
171 | css_set. |
172 | |
173 | - A css_set contains a set of reference-counted pointers to |
174 | cgroup_subsys_state objects, one for each cgroup subsystem |
175 | registered in the system. There is no direct link from a task to |
176 | the cgroup of which it's a member in each hierarchy, but this |
177 | can be determined by following pointers through the |
178 | cgroup_subsys_state objects. This is because accessing the |
179 | subsystem state is something that's expected to happen frequently |
180 | and in performance-critical code, whereas operations that require a |
181 | task's actual cgroup assignments (in particular, moving between |
182 | cgroups) are less common. A linked list runs through the cg_list |
183 | field of each task_struct using the css_set, anchored at |
184 | css_set->tasks. |
185 | |
186 | - A cgroup hierarchy filesystem can be mounted for browsing and |
187 | manipulation from user space. |
188 | |
189 | - You can list all the tasks (by pid) attached to any cgroup. |
190 | |
191 | The implementation of cgroups requires a few, simple hooks |
192 | into the rest of the kernel, none in performance critical paths: |
193 | |
194 | - in init/main.c, to initialize the root cgroups and initial |
195 | css_set at system boot. |
196 | |
197 | - in fork and exit, to attach and detach a task from its css_set. |
198 | |
199 | In addition a new file system, of type "cgroup" may be mounted, to |
200 | enable browsing and modifying the cgroups presently known to the |
201 | kernel. When mounting a cgroup hierarchy, you may specify a |
202 | comma-separated list of subsystems to mount as the filesystem mount |
203 | options. By default, mounting the cgroup filesystem attempts to |
204 | mount a hierarchy containing all registered subsystems. |
205 | |
206 | If an active hierarchy with exactly the same set of subsystems already |
207 | exists, it will be reused for the new mount. If no existing hierarchy |
208 | matches, and any of the requested subsystems are in use in an existing |
209 | hierarchy, the mount will fail with -EBUSY. Otherwise, a new hierarchy |
210 | is activated, associated with the requested subsystems. |
211 | |
212 | It's not currently possible to bind a new subsystem to an active |
213 | cgroup hierarchy, or to unbind a subsystem from an active cgroup |
214 | hierarchy. This may be possible in future, but is fraught with nasty |
215 | error-recovery issues. |
216 | |
217 | When a cgroup filesystem is unmounted, if there are any |
218 | child cgroups created below the top-level cgroup, that hierarchy |
219 | will remain active even though unmounted; if there are no |
220 | child cgroups then the hierarchy will be deactivated. |
221 | |
222 | No new system calls are added for cgroups - all support for |
223 | querying and modifying cgroups is via this cgroup file system. |
224 | |
225 | Each task under /proc has an added file named 'cgroup' displaying, |
226 | for each active hierarchy, the subsystem names and the cgroup name |
227 | as the path relative to the root of the cgroup file system. |
228 | |
229 | Each cgroup is represented by a directory in the cgroup file system |
230 | containing the following files describing that cgroup: |
231 | |
232 | - tasks: list of tasks (by pid) attached to that cgroup. This list |
233 | is not guaranteed to be sorted. Writing a thread id into this file |
234 | moves the thread into this cgroup. |
235 | - cgroup.procs: list of tgids in the cgroup. This list is not |
236 | guaranteed to be sorted or free of duplicate tgids, and userspace |
237 | should sort/uniquify the list if this property is required. |
238 | This is a read-only file, for now. |
239 | - notify_on_release flag: run the release agent on exit? |
240 | - release_agent: the path to use for release notifications (this file |
241 | exists in the top cgroup only) |
242 | |
243 | Other subsystems such as cpusets may add additional files in each |
244 | cgroup dir. |
245 | |
246 | New cgroups are created using the mkdir system call or shell |
247 | command. The properties of a cgroup, such as its flags, are |
248 | modified by writing to the appropriate file in that cgroups |
249 | directory, as listed above. |
250 | |
251 | The named hierarchical structure of nested cgroups allows partitioning |
252 | a large system into nested, dynamically changeable, "soft-partitions". |
253 | |
254 | The attachment of each task, automatically inherited at fork by any |
255 | children of that task, to a cgroup allows organizing the work load |
256 | on a system into related sets of tasks. A task may be re-attached to |
257 | any other cgroup, if allowed by the permissions on the necessary |
258 | cgroup file system directories. |
259 | |
260 | When a task is moved from one cgroup to another, it gets a new |
261 | css_set pointer - if there's an already existing css_set with the |
262 | desired collection of cgroups then that group is reused, else a new |
263 | css_set is allocated. The appropriate existing css_set is located by |
264 | looking into a hash table. |
265 | |
266 | To allow access from a cgroup to the css_sets (and hence tasks) |
267 | that comprise it, a set of cg_cgroup_link objects form a lattice; |
268 | each cg_cgroup_link is linked into a list of cg_cgroup_links for |
269 | a single cgroup on its cgrp_link_list field, and a list of |
270 | cg_cgroup_links for a single css_set on its cg_link_list. |
271 | |
272 | Thus the set of tasks in a cgroup can be listed by iterating over |
273 | each css_set that references the cgroup, and sub-iterating over |
274 | each css_set's task set. |
275 | |
276 | The use of a Linux virtual file system (vfs) to represent the |
277 | cgroup hierarchy provides for a familiar permission and name space |
278 | for cgroups, with a minimum of additional kernel code. |
279 | |
280 | 1.4 What does notify_on_release do ? |
281 | ------------------------------------ |
282 | |
283 | If the notify_on_release flag is enabled (1) in a cgroup, then |
284 | whenever the last task in the cgroup leaves (exits or attaches to |
285 | some other cgroup) and the last child cgroup of that cgroup |
286 | is removed, then the kernel runs the command specified by the contents |
287 | of the "release_agent" file in that hierarchy's root directory, |
288 | supplying the pathname (relative to the mount point of the cgroup |
289 | file system) of the abandoned cgroup. This enables automatic |
290 | removal of abandoned cgroups. The default value of |
291 | notify_on_release in the root cgroup at system boot is disabled |
292 | (0). The default value of other cgroups at creation is the current |
293 | value of their parents notify_on_release setting. The default value of |
294 | a cgroup hierarchy's release_agent path is empty. |
295 | |
296 | 1.5 How do I use cgroups ? |
297 | -------------------------- |
298 | |
299 | To start a new job that is to be contained within a cgroup, using |
300 | the "cpuset" cgroup subsystem, the steps are something like: |
301 | |
302 | 1) mkdir /dev/cgroup |
303 | 2) mount -t cgroup -ocpuset cpuset /dev/cgroup |
304 | 3) Create the new cgroup by doing mkdir's and write's (or echo's) in |
305 | the /dev/cgroup virtual file system. |
306 | 4) Start a task that will be the "founding father" of the new job. |
307 | 5) Attach that task to the new cgroup by writing its pid to the |
308 | /dev/cgroup tasks file for that cgroup. |
309 | 6) fork, exec or clone the job tasks from this founding father task. |
310 | |
311 | For example, the following sequence of commands will setup a cgroup |
312 | named "Charlie", containing just CPUs 2 and 3, and Memory Node 1, |
313 | and then start a subshell 'sh' in that cgroup: |
314 | |
315 | mount -t cgroup cpuset -ocpuset /dev/cgroup |
316 | cd /dev/cgroup |
317 | mkdir Charlie |
318 | cd Charlie |
319 | /bin/echo 2-3 > cpuset.cpus |
320 | /bin/echo 1 > cpuset.mems |
321 | /bin/echo $$ > tasks |
322 | sh |
323 | # The subshell 'sh' is now running in cgroup Charlie |
324 | # The next line should display '/Charlie' |
325 | cat /proc/self/cgroup |
326 | |
327 | 2. Usage Examples and Syntax |
328 | ============================ |
329 | |
330 | 2.1 Basic Usage |
331 | --------------- |
332 | |
333 | Creating, modifying, using the cgroups can be done through the cgroup |
334 | virtual filesystem. |
335 | |
336 | To mount a cgroup hierarchy with all available subsystems, type: |
337 | # mount -t cgroup xxx /dev/cgroup |
338 | |
339 | The "xxx" is not interpreted by the cgroup code, but will appear in |
340 | /proc/mounts so may be any useful identifying string that you like. |
341 | |
342 | To mount a cgroup hierarchy with just the cpuset and numtasks |
343 | subsystems, type: |
344 | # mount -t cgroup -o cpuset,memory hier1 /dev/cgroup |
345 | |
346 | To change the set of subsystems bound to a mounted hierarchy, just |
347 | remount with different options: |
348 | # mount -o remount,cpuset,ns hier1 /dev/cgroup |
349 | |
350 | Now memory is removed from the hierarchy and ns is added. |
351 | |
352 | Note this will add ns to the hierarchy but won't remove memory or |
353 | cpuset, because the new options are appended to the old ones: |
354 | # mount -o remount,ns /dev/cgroup |
355 | |
356 | To Specify a hierarchy's release_agent: |
357 | # mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \ |
358 | xxx /dev/cgroup |
359 | |
360 | Note that specifying 'release_agent' more than once will return failure. |
361 | |
362 | Note that changing the set of subsystems is currently only supported |
363 | when the hierarchy consists of a single (root) cgroup. Supporting |
364 | the ability to arbitrarily bind/unbind subsystems from an existing |
365 | cgroup hierarchy is intended to be implemented in the future. |
366 | |
367 | Then under /dev/cgroup you can find a tree that corresponds to the |
368 | tree of the cgroups in the system. For instance, /dev/cgroup |
369 | is the cgroup that holds the whole system. |
370 | |
371 | If you want to change the value of release_agent: |
372 | # echo "/sbin/new_release_agent" > /dev/cgroup/release_agent |
373 | |
374 | It can also be changed via remount. |
375 | |
376 | If you want to create a new cgroup under /dev/cgroup: |
377 | # cd /dev/cgroup |
378 | # mkdir my_cgroup |
379 | |
380 | Now you want to do something with this cgroup. |
381 | # cd my_cgroup |
382 | |
383 | In this directory you can find several files: |
384 | # ls |
385 | cgroup.procs notify_on_release tasks |
386 | (plus whatever files added by the attached subsystems) |
387 | |
388 | Now attach your shell to this cgroup: |
389 | # /bin/echo $$ > tasks |
390 | |
391 | You can also create cgroups inside your cgroup by using mkdir in this |
392 | directory. |
393 | # mkdir my_sub_cs |
394 | |
395 | To remove a cgroup, just use rmdir: |
396 | # rmdir my_sub_cs |
397 | |
398 | This will fail if the cgroup is in use (has cgroups inside, or |
399 | has processes attached, or is held alive by other subsystem-specific |
400 | reference). |
401 | |
402 | 2.2 Attaching processes |
403 | ----------------------- |
404 | |
405 | # /bin/echo PID > tasks |
406 | |
407 | Note that it is PID, not PIDs. You can only attach ONE task at a time. |
408 | If you have several tasks to attach, you have to do it one after another: |
409 | |
410 | # /bin/echo PID1 > tasks |
411 | # /bin/echo PID2 > tasks |
412 | ... |
413 | # /bin/echo PIDn > tasks |
414 | |
415 | You can attach the current shell task by echoing 0: |
416 | |
417 | # echo 0 > tasks |
418 | |
419 | 2.3 Mounting hierarchies by name |
420 | -------------------------------- |
421 | |
422 | Passing the name=<x> option when mounting a cgroups hierarchy |
423 | associates the given name with the hierarchy. This can be used when |
424 | mounting a pre-existing hierarchy, in order to refer to it by name |
425 | rather than by its set of active subsystems. Each hierarchy is either |
426 | nameless, or has a unique name. |
427 | |
428 | The name should match [\w.-]+ |
429 | |
430 | When passing a name=<x> option for a new hierarchy, you need to |
431 | specify subsystems manually; the legacy behaviour of mounting all |
432 | subsystems when none are explicitly specified is not supported when |
433 | you give a subsystem a name. |
434 | |
435 | The name of the subsystem appears as part of the hierarchy description |
436 | in /proc/mounts and /proc/<pid>/cgroups. |
437 | |
438 | 2.4 Notification API |
439 | -------------------- |
440 | |
441 | There is mechanism which allows to get notifications about changing |
442 | status of a cgroup. |
443 | |
444 | To register new notification handler you need: |
445 | - create a file descriptor for event notification using eventfd(2); |
446 | - open a control file to be monitored (e.g. memory.usage_in_bytes); |
447 | - write "<event_fd> <control_fd> <args>" to cgroup.event_control. |
448 | Interpretation of args is defined by control file implementation; |
449 | |
450 | eventfd will be woken up by control file implementation or when the |
451 | cgroup is removed. |
452 | |
453 | To unregister notification handler just close eventfd. |
454 | |
455 | NOTE: Support of notifications should be implemented for the control |
456 | file. See documentation for the subsystem. |
457 | |
458 | 3. Kernel API |
459 | ============= |
460 | |
461 | 3.1 Overview |
462 | ------------ |
463 | |
464 | Each kernel subsystem that wants to hook into the generic cgroup |
465 | system needs to create a cgroup_subsys object. This contains |
466 | various methods, which are callbacks from the cgroup system, along |
467 | with a subsystem id which will be assigned by the cgroup system. |
468 | |
469 | Other fields in the cgroup_subsys object include: |
470 | |
471 | - subsys_id: a unique array index for the subsystem, indicating which |
472 | entry in cgroup->subsys[] this subsystem should be managing. |
473 | |
474 | - name: should be initialized to a unique subsystem name. Should be |
475 | no longer than MAX_CGROUP_TYPE_NAMELEN. |
476 | |
477 | - early_init: indicate if the subsystem needs early initialization |
478 | at system boot. |
479 | |
480 | Each cgroup object created by the system has an array of pointers, |
481 | indexed by subsystem id; this pointer is entirely managed by the |
482 | subsystem; the generic cgroup code will never touch this pointer. |
483 | |
484 | 3.2 Synchronization |
485 | ------------------- |
486 | |
487 | There is a global mutex, cgroup_mutex, used by the cgroup |
488 | system. This should be taken by anything that wants to modify a |
489 | cgroup. It may also be taken to prevent cgroups from being |
490 | modified, but more specific locks may be more appropriate in that |
491 | situation. |
492 | |
493 | See kernel/cgroup.c for more details. |
494 | |
495 | Subsystems can take/release the cgroup_mutex via the functions |
496 | cgroup_lock()/cgroup_unlock(). |
497 | |
498 | Accessing a task's cgroup pointer may be done in the following ways: |
499 | - while holding cgroup_mutex |
500 | - while holding the task's alloc_lock (via task_lock()) |
501 | - inside an rcu_read_lock() section via rcu_dereference() |
502 | |
503 | 3.3 Subsystem API |
504 | ----------------- |
505 | |
506 | Each subsystem should: |
507 | |
508 | - add an entry in linux/cgroup_subsys.h |
509 | - define a cgroup_subsys object called <name>_subsys |
510 | |
511 | If a subsystem can be compiled as a module, it should also have in its |
512 | module initcall a call to cgroup_load_subsys(), and in its exitcall a |
513 | call to cgroup_unload_subsys(). It should also set its_subsys.module = |
514 | THIS_MODULE in its .c file. |
515 | |
516 | Each subsystem may export the following methods. The only mandatory |
517 | methods are create/destroy. Any others that are null are presumed to |
518 | be successful no-ops. |
519 | |
520 | struct cgroup_subsys_state *create(struct cgroup_subsys *ss, |
521 | struct cgroup *cgrp) |
522 | (cgroup_mutex held by caller) |
523 | |
524 | Called to create a subsystem state object for a cgroup. The |
525 | subsystem should allocate its subsystem state object for the passed |
526 | cgroup, returning a pointer to the new object on success or a |
527 | negative error code. On success, the subsystem pointer should point to |
528 | a structure of type cgroup_subsys_state (typically embedded in a |
529 | larger subsystem-specific object), which will be initialized by the |
530 | cgroup system. Note that this will be called at initialization to |
531 | create the root subsystem state for this subsystem; this case can be |
532 | identified by the passed cgroup object having a NULL parent (since |
533 | it's the root of the hierarchy) and may be an appropriate place for |
534 | initialization code. |
535 | |
536 | void destroy(struct cgroup_subsys *ss, struct cgroup *cgrp) |
537 | (cgroup_mutex held by caller) |
538 | |
539 | The cgroup system is about to destroy the passed cgroup; the subsystem |
540 | should do any necessary cleanup and free its subsystem state |
541 | object. By the time this method is called, the cgroup has already been |
542 | unlinked from the file system and from the child list of its parent; |
543 | cgroup->parent is still valid. (Note - can also be called for a |
544 | newly-created cgroup if an error occurs after this subsystem's |
545 | create() method has been called for the new cgroup). |
546 | |
547 | int pre_destroy(struct cgroup_subsys *ss, struct cgroup *cgrp); |
548 | |
549 | Called before checking the reference count on each subsystem. This may |
550 | be useful for subsystems which have some extra references even if |
551 | there are not tasks in the cgroup. If pre_destroy() returns error code, |
552 | rmdir() will fail with it. From this behavior, pre_destroy() can be |
553 | called multiple times against a cgroup. |
554 | |
555 | int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp, |
556 | struct task_struct *task, bool threadgroup) |
557 | (cgroup_mutex held by caller) |
558 | |
559 | Called prior to moving a task into a cgroup; if the subsystem |
560 | returns an error, this will abort the attach operation. If a NULL |
561 | task is passed, then a successful result indicates that *any* |
562 | unspecified task can be moved into the cgroup. Note that this isn't |
563 | called on a fork. If this method returns 0 (success) then this should |
564 | remain valid while the caller holds cgroup_mutex and it is ensured that either |
565 | attach() or cancel_attach() will be called in future. If threadgroup is |
566 | true, then a successful result indicates that all threads in the given |
567 | thread's threadgroup can be moved together. |
568 | |
569 | void cancel_attach(struct cgroup_subsys *ss, struct cgroup *cgrp, |
570 | struct task_struct *task, bool threadgroup) |
571 | (cgroup_mutex held by caller) |
572 | |
573 | Called when a task attach operation has failed after can_attach() has succeeded. |
574 | A subsystem whose can_attach() has some side-effects should provide this |
575 | function, so that the subsytem can implement a rollback. If not, not necessary. |
576 | This will be called only about subsystems whose can_attach() operation have |
577 | succeeded. |
578 | |
579 | void attach(struct cgroup_subsys *ss, struct cgroup *cgrp, |
580 | struct cgroup *old_cgrp, struct task_struct *task, |
581 | bool threadgroup) |
582 | (cgroup_mutex held by caller) |
583 | |
584 | Called after the task has been attached to the cgroup, to allow any |
585 | post-attachment activity that requires memory allocations or blocking. |
586 | If threadgroup is true, the subsystem should take care of all threads |
587 | in the specified thread's threadgroup. Currently does not support any |
588 | subsystem that might need the old_cgrp for every thread in the group. |
589 | |
590 | void fork(struct cgroup_subsy *ss, struct task_struct *task) |
591 | |
592 | Called when a task is forked into a cgroup. |
593 | |
594 | void exit(struct cgroup_subsys *ss, struct task_struct *task) |
595 | |
596 | Called during task exit. |
597 | |
598 | int populate(struct cgroup_subsys *ss, struct cgroup *cgrp) |
599 | (cgroup_mutex held by caller) |
600 | |
601 | Called after creation of a cgroup to allow a subsystem to populate |
602 | the cgroup directory with file entries. The subsystem should make |
603 | calls to cgroup_add_file() with objects of type cftype (see |
604 | include/linux/cgroup.h for details). Note that although this |
605 | method can return an error code, the error code is currently not |
606 | always handled well. |
607 | |
608 | void post_clone(struct cgroup_subsys *ss, struct cgroup *cgrp) |
609 | (cgroup_mutex held by caller) |
610 | |
611 | Called at the end of cgroup_clone() to do any parameter |
612 | initialization which might be required before a task could attach. For |
613 | example in cpusets, no task may attach before 'cpus' and 'mems' are set |
614 | up. |
615 | |
616 | void bind(struct cgroup_subsys *ss, struct cgroup *root) |
617 | (cgroup_mutex and ss->hierarchy_mutex held by caller) |
618 | |
619 | Called when a cgroup subsystem is rebound to a different hierarchy |
620 | and root cgroup. Currently this will only involve movement between |
621 | the default hierarchy (which never has sub-cgroups) and a hierarchy |
622 | that is being created/destroyed (and hence has no sub-cgroups). |
623 | |
624 | 4. Questions |
625 | ============ |
626 | |
627 | Q: what's up with this '/bin/echo' ? |
628 | A: bash's builtin 'echo' command does not check calls to write() against |
629 | errors. If you use it in the cgroup file system, you won't be |
630 | able to tell whether a command succeeded or failed. |
631 | |
632 | Q: When I attach processes, only the first of the line gets really attached ! |
633 | A: We can only return one error code per call to write(). So you should also |
634 | put only ONE pid. |
635 | |
636 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9