|
@@ -211,7 +211,7 @@ provide fair CPU time to each such task group. For example, it may be
|
|
|
desirable to first provide fair CPU time to each user on the system and then to
|
|
|
each task belonging to a user.
|
|
|
|
|
|
-CONFIG_GROUP_SCHED strives to achieve exactly that. It lets tasks to be
|
|
|
+CONFIG_CGROUP_SCHED strives to achieve exactly that. It lets tasks to be
|
|
|
grouped and divides CPU time fairly among such groups.
|
|
|
|
|
|
CONFIG_RT_GROUP_SCHED permits to group real-time (i.e., SCHED_FIFO and
|
|
@@ -220,38 +220,11 @@ SCHED_RR) tasks.
|
|
|
CONFIG_FAIR_GROUP_SCHED permits to group CFS (i.e., SCHED_NORMAL and
|
|
|
SCHED_BATCH) tasks.
|
|
|
|
|
|
-At present, there are two (mutually exclusive) mechanisms to group tasks for
|
|
|
-CPU bandwidth control purposes:
|
|
|
-
|
|
|
- - Based on user id (CONFIG_USER_SCHED)
|
|
|
-
|
|
|
- With this option, tasks are grouped according to their user id.
|
|
|
-
|
|
|
- - Based on "cgroup" pseudo filesystem (CONFIG_CGROUP_SCHED)
|
|
|
-
|
|
|
- This options needs CONFIG_CGROUPS to be defined, and lets the administrator
|
|
|
+ These options need CONFIG_CGROUPS to be defined, and let the administrator
|
|
|
create arbitrary groups of tasks, using the "cgroup" pseudo filesystem. See
|
|
|
Documentation/cgroups/cgroups.txt for more information about this filesystem.
|
|
|
|
|
|
-Only one of these options to group tasks can be chosen and not both.
|
|
|
-
|
|
|
-When CONFIG_USER_SCHED is defined, a directory is created in sysfs for each new
|
|
|
-user and a "cpu_share" file is added in that directory.
|
|
|
-
|
|
|
- # cd /sys/kernel/uids
|
|
|
- # cat 512/cpu_share # Display user 512's CPU share
|
|
|
- 1024
|
|
|
- # echo 2048 > 512/cpu_share # Modify user 512's CPU share
|
|
|
- # cat 512/cpu_share # Display user 512's CPU share
|
|
|
- 2048
|
|
|
- #
|
|
|
-
|
|
|
-CPU bandwidth between two users is divided in the ratio of their CPU shares.
|
|
|
-For example: if you would like user "root" to get twice the bandwidth of user
|
|
|
-"guest," then set the cpu_share for both the users such that "root"'s cpu_share
|
|
|
-is twice "guest"'s cpu_share.
|
|
|
-
|
|
|
-When CONFIG_CGROUP_SCHED is defined, a "cpu.shares" file is created for each
|
|
|
+When CONFIG_FAIR_GROUP_SCHED is defined, a "cpu.shares" file is created for each
|
|
|
group created using the pseudo filesystem. See example steps below to create
|
|
|
task groups and modify their CPU share using the "cgroups" pseudo filesystem.
|
|
|
|
|
@@ -273,24 +246,3 @@ task groups and modify their CPU share using the "cgroups" pseudo filesystem.
|
|
|
|
|
|
# #Launch gmplayer (or your favourite movie player)
|
|
|
# echo <movie_player_pid> > multimedia/tasks
|
|
|
-
|
|
|
-8. Implementation note: user namespaces
|
|
|
-
|
|
|
-User namespaces are intended to be hierarchical. But they are currently
|
|
|
-only partially implemented. Each of those has ramifications for CFS.
|
|
|
-
|
|
|
-First, since user namespaces are hierarchical, the /sys/kernel/uids
|
|
|
-presentation is inadequate. Eventually we will likely want to use sysfs
|
|
|
-tagging to provide private views of /sys/kernel/uids within each user
|
|
|
-namespace.
|
|
|
-
|
|
|
-Second, the hierarchical nature is intended to support completely
|
|
|
-unprivileged use of user namespaces. So if using user groups, then
|
|
|
-we want the users in a user namespace to be children of the user
|
|
|
-who created it.
|
|
|
-
|
|
|
-That is currently unimplemented. So instead, every user in a new
|
|
|
-user namespace will receive 1024 shares just like any user in the
|
|
|
-initial user namespace. Note that at the moment creation of a new
|
|
|
-user namespace requires each of CAP_SYS_ADMIN, CAP_SETUID, and
|
|
|
-CAP_SETGID.
|