Skip to content

Commit

Permalink
sched: Remove USER_SCHED from documentation
Browse files Browse the repository at this point in the history
USER_SCHED has been removed, so update the documentation
accordingly.

Signed-off-by: Li Zefan <[email protected]>
Signed-off-by: Peter Zijlstra <[email protected]>
Acked-by: Serge E. Hallyn <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
  • Loading branch information
Li Zefan authored and Ingo Molnar committed Apr 2, 2010
1 parent 32bd7eb commit 25c2d55
Show file tree
Hide file tree
Showing 2 changed files with 7 additions and 67 deletions.
54 changes: 3 additions & 51 deletions Documentation/scheduler/sched-design-CFS.txt
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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.

Expand All @@ -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.
20 changes: 4 additions & 16 deletions Documentation/scheduler/sched-rt-group.txt
Original file line number Diff line number Diff line change
Expand Up @@ -126,23 +126,12 @@ priority!
2.3 Basis for grouping tasks
----------------------------

There are two compile-time settings for allocating CPU bandwidth. These are
configured using the "Basis for grouping tasks" multiple choice menu under
General setup > Group CPU Scheduler:

a. CONFIG_USER_SCHED (aka "Basis for grouping tasks" = "user id")

This lets you use the virtual files under
"/sys/kernel/uids/<uid>/cpu_rt_runtime_us" to control he CPU time reserved for
each user .

The other option is:

.o CONFIG_CGROUP_SCHED (aka "Basis for grouping tasks" = "Control groups")
Enabling CONFIG_RT_GROUP_SCHED lets you explicitly allocate real
CPU bandwidth to task groups.

This uses the /cgroup virtual file system and
"/cgroup/<cgroup>/cpu.rt_runtime_us" to control the CPU time reserved for each
control group instead.
control group.

For more information on working with control groups, you should read
Documentation/cgroups/cgroups.txt as well.
Expand All @@ -161,8 +150,7 @@ For now, this can be simplified to just the following (but see Future plans):
===============

There is work in progress to make the scheduling period for each group
("/sys/kernel/uids/<uid>/cpu_rt_period_us" or
"/cgroup/<cgroup>/cpu.rt_period_us" respectively) configurable as well.
("/cgroup/<cgroup>/cpu.rt_period_us") configurable as well.

The constraint on the period is that a subgroup must have a smaller or
equal period to its parent. But realistically its not very useful _yet_
Expand Down

0 comments on commit 25c2d55

Please sign in to comment.