Chinaunix首页 | 论坛 | 博客
  • 博客访问: 888793
  • 博文数量: 116
  • 博客积分: 3923
  • 博客等级: 中校
  • 技术积分: 1337
  • 用 户 组: 普通用户
  • 注册时间: 2009-04-23 01:22








2011-12-04 23:06:28

  2. -------

  3. Written by Paul Menage based on
  4. Documentation/cgroups/cpusets.txt

  5. Original copyright statements from cpusets.txt:
  6. Portions Copyright (C) 2004 BULL SA.
  7. Portions Copyright (c) 2004-2006 Silicon Graphics, Inc.
  8. Modified by Paul Jackson
  9. Modified by Christoph Lameter

  11. =========

  12. 1. Control Groups
  13. 1.1 What are cgroups ?
  14. 1.2 Why are cgroups needed ?
  15. 1.3 How are cgroups implemented ?
  16. 1.4 What does notify_on_release do ?
  17. 1.5 What does clone_children do ?
  18. 1.6 How do I use cgroups ?
  19. 2. Usage Examples and Syntax
  20. 2.1 Basic Usage
  21. 2.2 Attaching processes
  22. 2.3 Mounting hierarchies by name
  23. 2.4 Notification API
  24. 3. Kernel API
  25. 3.1 Overview
  26. 3.2 Synchronization
  27. 3.3 Subsystem API
  28. 4. Questions

  29. 1. Control Groups
  30. =================

  31. 1.1 What are cgroups ?
  32. ----------------------

  33. Control Groups provide a mechanism for aggregating/partitioning sets of
  34. tasks, and all their future children, into hierarchical groups with
  35. specialized behaviour.

  36. Definitions:

  37. A *cgroup* associates a set of tasks with a set of parameters for one
  38. or more subsystems.

  39. A *subsystem* is a module that makes use of the task grouping
  40. facilities provided by cgroups to treat groups of tasks in
  41. particular ways. A subsystem is typically a "resource controller" that
  42. schedules a resource or applies per-cgroup limits, but it may be
  43. anything that wants to act on a group of processes, e.g. a
  44. virtualization subsystem.

  45. A *hierarchy* is a set of cgroups arranged in a tree, such that
  46. every task in the system is in exactly one of the cgroups in the
  47. hierarchy, and a set of subsystems; each subsystem has system-specific
  48. state attached to each cgroup in the hierarchy. Each hierarchy has
  49. an instance of the cgroup virtual filesystem associated with it.

  50. At any one time there may be multiple active hierarchies of task
  51. cgroups. Each hierarchy is a partition of all tasks in the system.

  52. User level code may create and destroy cgroups by name in an
  53. instance of the cgroup virtual file system, specify and query to
  54. which cgroup a task is assigned, and list the task pids assigned to
  55. a cgroup. Those creations and assignments only affect the hierarchy
  56. associated with that instance of the cgroup file system.

  57. On their own, the only use for cgroups is for simple job
  58. tracking. The intention is that other subsystems hook into the generic
  59. cgroup support to provide new attributes for cgroups, such as
  60. accounting/limiting the resources which processes in a cgroup can
  61. access. For example, cpusets (see Documentation/cgroups/cpusets.txt) allows
  62. you to associate a set of CPUs and a set of memory nodes with the
  63. tasks in each cgroup.

  64. 1.2 Why are cgroups needed ?
  65. ----------------------------

  66. There are multiple efforts to provide process aggregations in the
  67. Linux kernel, mainly for resource tracking purposes. Such efforts
  68. include cpusets, CKRM/ResGroups, UserBeanCounters, and virtual server
  69. namespaces. These all require the basic notion of a
  70. grouping/partitioning of processes, with newly forked processes ending
  71. in the same group (cgroup) as their parent process.

  72. The kernel cgroup patch provides the minimum essential kernel
  73. mechanisms required to efficiently implement such groups. It has
  74. minimal impact on the system fast paths, and provides hooks for
  75. specific subsystems such as cpusets to provide additional behaviour as
  76. desired.

  77. Multiple hierarchy support is provided to allow for situations where
  78. the division of tasks into cgroups is distinctly different for
  79. different subsystems - having parallel hierarchies allows each
  80. hierarchy to be a natural division of tasks, without having to handle
  81. complex combinations of tasks that would be present if several
  82. unrelated subsystems needed to be forced into the same tree of
  83. cgroups.

  84. At one extreme, each resource controller or subsystem could be in a
  85. separate hierarchy; at the other extreme, all subsystems
  86. would be attached to the same hierarchy.

  87. As an example of a scenario (originally proposed by
  88. that can benefit from multiple hierarchies, consider a large
  89. university server with various users - students, professors, system
  90. tasks etc. The resource planning for this server could be along the
  91. following lines:

  92. CPU : "Top cpuset"
  93. / \
  94. CPUSet1 CPUSet2
  95. | |
  96. (Professors) (Students)

  97. In addition (system tasks) are attached to topcpuset (so
  98. that they can run anywhere) with a limit of 20%

  99. Memory : Professors (50%), Students (30%), system (20%)

  100. Disk : Professors (50%), Students (30%), system (20%)

  101. Network : WWW browsing (20%), Network File System (60%), others (20%)
  102. / \
  103. Professors (15%) students (5%)

  104. Browsers like Firefox/Lynx go into the WWW network class, while (k)nfsd go
  105. into NFS network class.

  106. At the same time Firefox/Lynx will share an appropriate CPU/Memory class
  107. depending on who launched it (prof/student).

  108. With the ability to classify tasks differently for different resources
  109. (by putting those resource subsystems in different hierarchies) then
  110. the admin can easily set up a script which receives exec notifications
  111. and depending on who is launching the browser he can

  112. # echo browser_pid > /sys/fs/cgroup///tasks

  113. With only a single hierarchy, he now would potentially have to create
  114. a separate cgroup for every browser launched and associate it with
  115. appropriate network and other resource class. This may lead to
  116. proliferation of such cgroups.

  117. Also lets say that the administrator would like to give enhanced network
  118. access temporarily to a student's browser (since it is night and the user
  119. wants to do online gaming :)) OR give one of the students simulation
  120. apps enhanced CPU power,

  121. With ability to write pids directly to resource classes, it's just a
  122. matter of :

  123. # echo pid > /sys/fs/cgroup/network//tasks
  124. (after some time)
  125. # echo pid > /sys/fs/cgroup/network//tasks

  126. Without this ability, he would have to split the cgroup into
  127. multiple separate ones and then associate the new cgroups with the
  128. new resource classes.

  129. 1.3 How are cgroups implemented ?
  130. ---------------------------------

  131. Control Groups extends the kernel as follows:

  132. - Each task in the system has a reference-counted pointer to a
  133. css_set.

  134. - A css_set contains a set of reference-counted pointers to
  135. cgroup_subsys_state objects, one for each cgroup subsystem
  136. registered in the system. There is no direct link from a task to
  137. the cgroup of which it's a member in each hierarchy, but this
  138. can be determined by following pointers through the
  139. cgroup_subsys_state objects. This is because accessing the
  140. subsystem state is something that's expected to happen frequently
  141. and in performance-critical code, whereas operations that require a
  142. task's actual cgroup assignments (in particular, moving between
  143. cgroups) are less common. A linked list runs through the cg_list
  144. field of each task_struct using the css_set, anchored at
  145. css_set->tasks.

  146. - A cgroup hierarchy filesystem can be mounted for browsing and
  147. manipulation from user space.

  148. - You can list all the tasks (by pid) attached to any cgroup.

  149. The implementation of cgroups requires a few, simple hooks
  150. into the rest of the kernel, none in performance critical paths:

  151. - in init/main.c, to initialize the root cgroups and initial
  152. css_set at system boot.

  153. - in fork and exit, to attach and detach a task from its css_set.

  154. In addition a new file system, of type "cgroup" may be mounted, to
  155. enable browsing and modifying the cgroups presently known to the
  156. kernel. When mounting a cgroup hierarchy, you may specify a
  157. comma-separated list of subsystems to mount as the filesystem mount
  158. options. By default, mounting the cgroup filesystem attempts to
  159. mount a hierarchy containing all registered subsystems.

  160. If an active hierarchy with exactly the same set of subsystems already
  161. exists, it will be reused for the new mount. If no existing hierarchy
  162. matches, and any of the requested subsystems are in use in an existing
  163. hierarchy, the mount will fail with -EBUSY. Otherwise, a new hierarchy
  164. is activated, associated with the requested subsystems.

  165. It's not currently possible to bind a new subsystem to an active
  166. cgroup hierarchy, or to unbind a subsystem from an active cgroup
  167. hierarchy. This may be possible in future, but is fraught with nasty
  168. error-recovery issues.

  169. When a cgroup filesystem is unmounted, if there are any
  170. child cgroups created below the top-level cgroup, that hierarchy
  171. will remain active even though unmounted; if there are no
  172. child cgroups then the hierarchy will be deactivated.

  173. No new system calls are added for cgroups - all support for
  174. querying and modifying cgroups is via this cgroup file system.

  175. Each task under /proc has an added file named 'cgroup' displaying,
  176. for each active hierarchy, the subsystem names and the cgroup name
  177. as the path relative to the root of the cgroup file system.

  178. Each cgroup is represented by a directory in the cgroup file system
  179. containing the following files describing that cgroup:

  180. - tasks: list of tasks (by pid) attached to that cgroup. This list
  181. is not guaranteed to be sorted. Writing a thread id into this file
  182. moves the thread into this cgroup.
  183. - cgroup.procs: list of tgids in the cgroup. This list is not
  184. guaranteed to be sorted or free of duplicate tgids, and userspace
  185. should sort/uniquify the list if this property is required.
  186. Writing a thread group id into this file moves all threads in that
  187. group into this cgroup.
  188. - notify_on_release flag: run the release agent on exit?
  189. - release_agent: the path to use for release notifications (this file
  190. exists in the top cgroup only)

  191. Other subsystems such as cpusets may add additional files in each
  192. cgroup dir.

  193. New cgroups are created using the mkdir system call or shell
  194. command. The properties of a cgroup, such as its flags, are
  195. modified by writing to the appropriate file in that cgroups
  196. directory, as listed above.

  197. The named hierarchical structure of nested cgroups allows partitioning
  198. a large system into nested, dynamically changeable, "soft-partitions".

  199. The attachment of each task, automatically inherited at fork by any
  200. children of that task, to a cgroup allows organizing the work load
  201. on a system into related sets of tasks. A task may be re-attached to
  202. any other cgroup, if allowed by the permissions on the necessary
  203. cgroup file system directories.

  204. When a task is moved from one cgroup to another, it gets a new
  205. css_set pointer - if there's an already existing css_set with the
  206. desired collection of cgroups then that group is reused, else a new
  207. css_set is allocated. The appropriate existing css_set is located by
  208. looking into a hash table.

  209. To allow access from a cgroup to the css_sets (and hence tasks)
  210. that comprise it, a set of cg_cgroup_link objects form a lattice;
  211. each cg_cgroup_link is linked into a list of cg_cgroup_links for
  212. a single cgroup on its cgrp_link_list field, and a list of
  213. cg_cgroup_links for a single css_set on its cg_link_list.

  214. Thus the set of tasks in a cgroup can be listed by iterating over
  215. each css_set that references the cgroup, and sub-iterating over
  216. each css_set's task set.

  217. The use of a Linux virtual file system (vfs) to represent the
  218. cgroup hierarchy provides for a familiar permission and name space
  219. for cgroups, with a minimum of additional kernel code.

  220. 1.4 What does notify_on_release do ?
  221. ------------------------------------

  222. If the notify_on_release flag is enabled (1) in a cgroup, then
  223. whenever the last task in the cgroup leaves (exits or attaches to
  224. some other cgroup) and the last child cgroup of that cgroup
  225. is removed, then the kernel runs the command specified by the contents
  226. of the "release_agent" file in that hierarchy's root directory,
  227. supplying the pathname (relative to the mount point of the cgroup
  228. file system) of the abandoned cgroup. This enables automatic
  229. removal of abandoned cgroups. The default value of
  230. notify_on_release in the root cgroup at system boot is disabled
  231. (0). The default value of other cgroups at creation is the current
  232. value of their parents notify_on_release setting. The default value of
  233. a cgroup hierarchy's release_agent path is empty.

  234. 1.5 What does clone_children do ?
  235. ---------------------------------

  236. If the clone_children flag is enabled (1) in a cgroup, then all
  237. cgroups created beneath will call the post_clone callbacks for each
  238. subsystem of the newly created cgroup. Usually when this callback is
  239. implemented for a subsystem, it copies the values of the parent
  240. subsystem, this is the case for the cpuset.

  241. 1.6 How do I use cgroups ?
  242. --------------------------

  243. To start a new job that is to be contained within a cgroup, using
  244. the "cpuset" cgroup subsystem, the steps are something like:

  245. 1) mount -t tmpfs cgroup_root /sys/fs/cgroup
  246. 2) mkdir /sys/fs/cgroup/cpuset
  247. 3) mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset
  248. 4) Create the new cgroup by doing mkdir's and write's (or echo's) in
  249. the /sys/fs/cgroup virtual file system.
  250. 5) Start a task that will be the "founding father" of the new job.
  251. 6) Attach that task to the new cgroup by writing its pid to the
  252. /sys/fs/cgroup/cpuset/tasks file for that cgroup.
  253. 7) fork, exec or clone the job tasks from this founding father task.

  254. For example, the following sequence of commands will setup a cgroup
  255. named "Charlie", containing just CPUs 2 and 3, and Memory Node 1,
  256. and then start a subshell 'sh' in that cgroup:

  257. mount -t tmpfs cgroup_root /sys/fs/cgroup
  258. mkdir /sys/fs/cgroup/cpuset
  259. mount -t cgroup cpuset -ocpuset /sys/fs/cgroup/cpuset
  260. cd /sys/fs/cgroup/cpuset
  261. mkdir Charlie
  262. cd Charlie
  263. /bin/echo 2-3 > cpuset.cpus
  264. /bin/echo 1 > cpuset.mems
  265. /bin/echo $$ > tasks
  266. sh
  267. # The subshell 'sh' is now running in cgroup Charlie
  268. # The next line should display '/Charlie'
  269. cat /proc/self/cgroup

  270. 2. Usage Examples and Syntax
  271. ============================

  272. 2.1 Basic Usage
  273. ---------------

  274. Creating, modifying, using the cgroups can be done through the cgroup
  275. virtual filesystem.

  276. To mount a cgroup hierarchy with all available subsystems, type:
  277. # mount -t cgroup xxx /sys/fs/cgroup

  278. The "xxx" is not interpreted by the cgroup code, but will appear in
  279. /proc/mounts so may be any useful identifying string that you like.

  280. Note: Some subsystems do not work without some user input first. For instance,
  281. if cpusets are enabled the user will have to populate the cpus and mems files
  282. for each new cgroup created before that group can be used.

  283. As explained in section `1.2 Why are cgroups needed?' you should create
  284. different hierarchies of cgroups for each single resource or group of
  285. resources you want to control. Therefore, you should mount a tmpfs on
  286. /sys/fs/cgroup and create directories for each cgroup resource or resource
  287. group.

  288. # mount -t tmpfs cgroup_root /sys/fs/cgroup
  289. # mkdir /sys/fs/cgroup/rg1

  290. To mount a cgroup hierarchy with just the cpuset and memory
  291. subsystems, type:
  292. # mount -t cgroup -o cpuset,memory hier1 /sys/fs/cgroup/rg1

  293. To change the set of subsystems bound to a mounted hierarchy, just
  294. remount with different options:
  295. # mount -o remount,cpuset,blkio hier1 /sys/fs/cgroup/rg1

  296. Now memory is removed from the hierarchy and blkio is added.

  297. Note this will add blkio to the hierarchy but won't remove memory or
  298. cpuset, because the new options are appended to the old ones:
  299. # mount -o remount,blkio /sys/fs/cgroup/rg1

  300. To Specify a hierarchy's release_agent:
  301. # mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \
  302. xxx /sys/fs/cgroup/rg1

  303. Note that specifying 'release_agent' more than once will return failure.

  304. Note that changing the set of subsystems is currently only supported
  305. when the hierarchy consists of a single (root) cgroup. Supporting
  306. the ability to arbitrarily bind/unbind subsystems from an existing
  307. cgroup hierarchy is intended to be implemented in the future.

  308. Then under /sys/fs/cgroup/rg1 you can find a tree that corresponds to the
  309. tree of the cgroups in the system. For instance, /sys/fs/cgroup/rg1
  310. is the cgroup that holds the whole system.

  311. If you want to change the value of release_agent:
  312. # echo "/sbin/new_release_agent" > /sys/fs/cgroup/rg1/release_agent

  313. It can also be changed via remount.

  314. If you want to create a new cgroup under /sys/fs/cgroup/rg1:
  315. # cd /sys/fs/cgroup/rg1
  316. # mkdir my_cgroup

  317. Now you want to do something with this cgroup.
  318. # cd my_cgroup

  319. In this directory you can find several files:
  320. # ls
  321. cgroup.procs notify_on_release tasks
  322. (plus whatever files added by the attached subsystems)

  323. Now attach your shell to this cgroup:
  324. # /bin/echo $$ > tasks

  325. You can also create cgroups inside your cgroup by using mkdir in this
  326. directory.
  327. # mkdir my_sub_cs

  328. To remove a cgroup, just use rmdir:
  329. # rmdir my_sub_cs

  330. This will fail if the cgroup is in use (has cgroups inside, or
  331. has processes attached, or is held alive by other subsystem-specific
  332. reference).

  333. 2.2 Attaching processes
  334. -----------------------

  335. # /bin/echo PID > tasks

  336. Note that it is PID, not PIDs. You can only attach ONE task at a time.
  337. If you have several tasks to attach, you have to do it one after another:

  338. # /bin/echo PID1 > tasks
  339. # /bin/echo PID2 > tasks
  340. ...
  341. # /bin/echo PIDn > tasks

  342. You can attach the current shell task by echoing 0:

  343. # echo 0 > tasks

  344. You can use the cgroup.procs file instead of the tasks file to move all
  345. threads in a threadgroup at once. Echoing the pid of any task in a
  346. threadgroup to cgroup.procs causes all tasks in that threadgroup to be
  347. be attached to the cgroup. Writing 0 to cgroup.procs moves all tasks
  348. in the writing task's threadgroup.

  349. Note: Since every task is always a member of exactly one cgroup in each
  350. mounted hierarchy, to remove a task from its current cgroup you must
  351. move it into a new cgroup (possibly the root cgroup) by writing to the
  352. new cgroup's tasks file.

  353. Note: If the ns cgroup is active, moving a process to another cgroup can
  354. fail.

  355. 2.3 Mounting hierarchies by name
  356. --------------------------------

  357. Passing the name= option when mounting a cgroups hierarchy
  358. associates the given name with the hierarchy. This can be used when
  359. mounting a pre-existing hierarchy, in order to refer to it by name
  360. rather than by its set of active subsystems. Each hierarchy is either
  361. nameless, or has a unique name.

  362. The name should match [\w.-]+

  363. When passing a name= option for a new hierarchy, you need to
  364. specify subsystems manually; the legacy behaviour of mounting all
  365. subsystems when none are explicitly specified is not supported when
  366. you give a subsystem a name.

  367. The name of the subsystem appears as part of the hierarchy description
  368. in /proc/mounts and /proc//cgroups.

  369. 2.4 Notification API
  370. --------------------

  371. There is mechanism which allows to get notifications about changing
  372. status of a cgroup.

  373. To register new notification handler you need:
  374. - create a file descriptor for event notification using eventfd(2);
  375. - open a control file to be monitored (e.g. memory.usage_in_bytes);
  376. - write " " to cgroup.event_control.
  377. Interpretation of args is defined by control file implementation;

  378. eventfd will be woken up by control file implementation or when the
  379. cgroup is removed.

  380. To unregister notification handler just close eventfd.

  381. NOTE: Support of notifications should be implemented for the control
  382. file. See documentation for the subsystem.

  383. 3. Kernel API
  384. =============

  385. 3.1 Overview
  386. ------------

  387. Each kernel subsystem that wants to hook into the generic cgroup
  388. system needs to create a cgroup_subsys object. This contains
  389. various methods, which are callbacks from the cgroup system, along
  390. with a subsystem id which will be assigned by the cgroup system.

  391. Other fields in the cgroup_subsys object include:

  392. - subsys_id: a unique array index for the subsystem, indicating which
  393. entry in cgroup->subsys[] this subsystem should be managing.

  394. - name: should be initialized to a unique subsystem name. Should be
  395. no longer than MAX_CGROUP_TYPE_NAMELEN.

  396. - early_init: indicate if the subsystem needs early initialization
  397. at system boot.

  398. Each cgroup object created by the system has an array of pointers,
  399. indexed by subsystem id; this pointer is entirely managed by the
  400. subsystem; the generic cgroup code will never touch this pointer.

  401. 3.2 Synchronization
  402. -------------------

  403. There is a global mutex, cgroup_mutex, used by the cgroup
  404. system. This should be taken by anything that wants to modify a
  405. cgroup. It may also be taken to prevent cgroups from being
  406. modified, but more specific locks may be more appropriate in that
  407. situation.

  408. See kernel/cgroup.c for more details.

  409. Subsystems can take/release the cgroup_mutex via the functions
  410. cgroup_lock()/cgroup_unlock().

  411. Accessing a task's cgroup pointer may be done in the following ways:
  412. - while holding cgroup_mutex
  413. - while holding the task's alloc_lock (via task_lock())
  414. - inside an rcu_read_lock() section via rcu_dereference()

  415. 3.3 Subsystem API
  416. -----------------

  417. Each subsystem should:

  418. - add an entry in linux/cgroup_subsys.h
  419. - define a cgroup_subsys object called _subsys

  420. If a subsystem can be compiled as a module, it should also have in its
  421. module initcall a call to cgroup_load_subsys(), and in its exitcall a
  422. call to cgroup_unload_subsys(). It should also set its_subsys.module =
  423. THIS_MODULE in its .c file.

  424. Each subsystem may export the following methods. The only mandatory
  425. methods are create/destroy. Any others that are null are presumed to
  426. be successful no-ops.

  427. struct cgroup_subsys_state *create(struct cgroup_subsys *ss,
  428. struct cgroup *cgrp)
  429. (cgroup_mutex held by caller)

  430. Called to create a subsystem state object for a cgroup. The
  431. subsystem should allocate its subsystem state object for the passed
  432. cgroup, returning a pointer to the new object on success or a
  433. negative error code. On success, the subsystem pointer should point to
  434. a structure of type cgroup_subsys_state (typically embedded in a
  435. larger subsystem-specific object), which will be initialized by the
  436. cgroup system. Note that this will be called at initialization to
  437. create the root subsystem state for this subsystem; this case can be
  438. identified by the passed cgroup object having a NULL parent (since
  439. it's the root of the hierarchy) and may be an appropriate place for
  440. initialization code.

  441. void destroy(struct cgroup_subsys *ss, struct cgroup *cgrp)
  442. (cgroup_mutex held by caller)

  443. The cgroup system is about to destroy the passed cgroup; the subsystem
  444. should do any necessary cleanup and free its subsystem state
  445. object. By the time this method is called, the cgroup has already been
  446. unlinked from the file system and from the child list of its parent;
  447. cgroup->parent is still valid. (Note - can also be called for a
  448. newly-created cgroup if an error occurs after this subsystem's
  449. create() method has been called for the new cgroup).

  450. int pre_destroy(struct cgroup_subsys *ss, struct cgroup *cgrp);

  451. Called before checking the reference count on each subsystem. This may
  452. be useful for subsystems which have some extra references even if
  453. there are not tasks in the cgroup. If pre_destroy() returns error code,
  454. rmdir() will fail with it. From this behavior, pre_destroy() can be
  455. called multiple times against a cgroup.

  456. int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
  457. struct task_struct *task)
  458. (cgroup_mutex held by caller)

  459. Called prior to moving a task into a cgroup; if the subsystem
  460. returns an error, this will abort the attach operation. If a NULL
  461. task is passed, then a successful result indicates that *any*
  462. unspecified task can be moved into the cgroup. Note that this isn't
  463. called on a fork. If this method returns 0 (success) then this should
  464. remain valid while the caller holds cgroup_mutex and it is ensured that either
  465. attach() or cancel_attach() will be called in future.

  466. int can_attach_task(struct cgroup *cgrp, struct task_struct *tsk);
  467. (cgroup_mutex held by caller)

  468. As can_attach, but for operations that must be run once per task to be
  469. attached (possibly many when using cgroup_attach_proc). Called after
  470. can_attach.

  471. void cancel_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
  472. struct task_struct *task, bool threadgroup)
  473. (cgroup_mutex held by caller)

  474. Called when a task attach operation has failed after can_attach() has succeeded.
  475. A subsystem whose can_attach() has some side-effects should provide this
  476. function, so that the subsystem can implement a rollback. If not, not necessary.
  477. This will be called only about subsystems whose can_attach() operation have
  478. succeeded.

  479. void pre_attach(struct cgroup *cgrp);
  480. (cgroup_mutex held by caller)

  481. For any non-per-thread attachment work that needs to happen before
  482. attach_task. Needed by cpuset.

  483. void attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
  484. struct cgroup *old_cgrp, struct task_struct *task)
  485. (cgroup_mutex held by caller)

  486. Called after the task has been attached to the cgroup, to allow any
  487. post-attachment activity that requires memory allocations or blocking.

  488. void attach_task(struct cgroup *cgrp, struct task_struct *tsk);
  489. (cgroup_mutex held by caller)

  490. As attach, but for operations that must be run once per task to be attached,
  491. like can_attach_task. Called before attach. Currently does not support any
  492. subsystem that might need the old_cgrp for every thread in the group.

  493. void fork(struct cgroup_subsy *ss, struct task_struct *task)

  494. Called when a task is forked into a cgroup.

  495. void exit(struct cgroup_subsys *ss, struct task_struct *task)

  496. Called during task exit.

  497. int populate(struct cgroup_subsys *ss, struct cgroup *cgrp)
  498. (cgroup_mutex held by caller)

  499. Called after creation of a cgroup to allow a subsystem to populate
  500. the cgroup directory with file entries. The subsystem should make
  501. calls to cgroup_add_file() with objects of type cftype (see
  502. include/linux/cgroup.h for details). Note that although this
  503. method can return an error code, the error code is currently not
  504. always handled well.

  505. void post_clone(struct cgroup_subsys *ss, struct cgroup *cgrp)
  506. (cgroup_mutex held by caller)

  507. Called during cgroup_create() to do any parameter
  508. initialization which might be required before a task could attach. For
  509. example in cpusets, no task may attach before 'cpus' and 'mems' are set
  510. up.

  511. void bind(struct cgroup_subsys *ss, struct cgroup *root)
  512. (cgroup_mutex and ss->hierarchy_mutex held by caller)

  513. Called when a cgroup subsystem is rebound to a different hierarchy
  514. and root cgroup. Currently this will only involve movement between
  515. the default hierarchy (which never has sub-cgroups) and a hierarchy
  516. that is being created/destroyed (and hence has no sub-cgroups).

  517. 4. Questions
  518. ============

  519. Q: what's up with this '/bin/echo' ?
  520. A: bash's builtin 'echo' command does not check calls to write() against
  521. errors. If you use it in the cgroup file system, you won't be
  522. able to tell whether a command succeeded or failed.

  523. Q: When I attach processes, only the first of the line gets really attached !
  524. A: We can only return one error code per call to write(). So you should also
  525. put only ONE pid.

阅读(2133) | 评论(0) | 转发(0) |