Merge branch 'sched/core' of...

    Linus, usually the patches that have already been included in the

    -next kernel for a few weeks.  The preferred way to submit big changes

    is using git (the kernel's source management tool, more information

    can be found at http://git.or.cz/) but plain patches are also just

    can be found at http://git-scm.com/) but plain patches are also just

    fine.

  - After two weeks a -rc1 kernel is released it is now possible to push

    only patches that do not include new features that could affect the

	sched_expedited-torture: Reader Pipe:  12660320201 95875 0 0 0 0 0 0 0 0 0

	sched_expedited-torture: Reader Batch:  12660424885 0 0 0 0 0 0 0 0 0 0

	sched_expedited-torture: Free-Block Circulation:  1090795 1090795 1090794 1090793 1090792 1090791 1090790 1090789 1090788 1090787 0

	state: -1 / 0:0 3:0 4:0

As before, the first four lines are similar to those for RCU.

The last line shows the task-migration state.  The first number is

-1 if synchronize_sched_expedited() is idle, -2 if in the process of

posting wakeups to the migration kthreads, and N when waiting on CPU N.

Each of the colon-separated fields following the "/" is a CPU:state pair.

Valid states are "0" for idle, "1" for waiting for quiescent state,

"2" for passed through quiescent state, and "3" when a race with a

CPU-hotplug event forces use of the synchronize_sched() primitive.

USAGE

 - cgroup.procs: list of tgids in the cgroup.  This list is not

   guaranteed to be sorted or free of duplicate tgids, and userspace

   should sort/uniquify the list if this property is required.

   Writing a tgid into this file moves all threads with that tgid into

   this cgroup.

   This is a read-only file, for now.

 - notify_on_release flag: run the release agent on exit?

 - release_agent: the path to use for release notifications (this file

   exists in the top cgroup only)

	libata.force=	[LIBATA] Force configurations.  The format is comma

			separated list of "[ID:]VAL" where ID is

			PORT[:DEVICE].  PORT and DEVICE are decimal numbers

			PORT[.DEVICE].  PORT and DEVICE are decimal numbers

			matching port, link or device.  Basically, it matches

			the ATA ID string printed on console by libata.  If

			the whole ID part is omitted, the last PORT and DEVICE

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

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.

	# #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.