Merge branch 'master' of /pub/scm/linux/kernel/git/torvalds/linux-2.6

returns non zero. If v is equal to u then it returns zero. This is done as

an atomic operation.

atomic_add_unless requires explicit memory barriers around the operation.

atomic_add_unless requires explicit memory barriers around the operation

unless it fails (returns 0).

atomic_inc_not_zero, equivalent to atomic_add_unless(v, 1, 0)

4. Questions

1. Control Groups

==========

=================

1.1 What are cgroups ?

----------------------

Also lets say that the administrator would like to give enhanced network

access temporarily to a student's browser (since it is night and the user

wants to do online gaming :)  OR give one of the students simulation

wants to do online gaming :))  OR give one of the students simulation

apps enhanced CPU power,

With ability to write pids directly to resource classes, its just a

With ability to write pids directly to resource classes, it's just a

matter of :

       # echo pid > /mnt/network/<new_class>/tasks

containing the following files describing that cgroup:

 - tasks: list of tasks (by pid) attached to that cgroup

 - notify_on_release flag: run /sbin/cgroup_release_agent on exit?

 - releasable flag: cgroup currently removeable?

 - 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)

Other subsystems such as cpusets may add additional files in each

cgroup dir

cgroup dir.

New cgroups are created using the mkdir system call or shell

command.  The properties of a cgroup, such as its flags, are

To allow access from a cgroup to the css_sets (and hence tasks)

that comprise it, a set of cg_cgroup_link objects form a lattice;

each cg_cgroup_link is linked into a list of cg_cgroup_links for

a single cgroup on its cont_link_list field, and a list of

a single cgroup on its cgrp_link_list field, and a list of

cg_cgroup_links for a single css_set on its cg_link_list.

Thus the set of tasks in a cgroup can be listed by iterating over

1.4 What does notify_on_release do ?

------------------------------------

*** notify_on_release is disabled in the current patch set. It will be

*** reactivated in a future patch in a less-intrusive manner

If the notify_on_release flag is enabled (1) in a cgroup, then

whenever the last task in the cgroup leaves (exits or attaches to

some other cgroup) and the last child cgroup of that cgroup

In this directory you can find several files:

# ls

notify_on_release release_agent tasks

(plus whatever files are added by the attached subsystems)

notify_on_release releasable tasks

(plus whatever files added by the attached subsystems)

Now attach your shell to this cgroup:

# /bin/echo $$ > tasks

Other fields in the cgroup_subsys object include:

- subsys_id: a unique array index for the subsystem, indicating which

  entry in cgroup->subsys[] this subsystem should be

  managing. Initialized by cgroup_register_subsys(); prior to this

  it should be initialized to -1

  entry in cgroup->subsys[] this subsystem should be managing.

- hierarchy: an index indicating which hierarchy, if any, this

  subsystem is currently attached to. If this is -1, then the

  subsystem is not attached to any hierarchy, and all tasks should be

  considered to be members of the subsystem's top_cgroup. It should

  be initialized to -1.

- name: should be initialized to a unique subsystem name. Should be

  no longer than MAX_CGROUP_TYPE_NAMELEN.

- name: should be initialized to a unique subsystem name prior to

  calling cgroup_register_subsystem. Should be no longer than

  MAX_CGROUP_TYPE_NAMELEN

- early_init: indicate if the subsystem needs early initialization

  at system boot.

Each cgroup object created by the system has an array of pointers,

indexed by subsystem id; this pointer is entirely managed by the

See kernel/cgroup.c for more details.

Subsystems can take/release the cgroup_mutex via the functions

cgroup_lock()/cgroup_unlock(), and can

take/release the callback_mutex via the functions

cgroup_lock()/cgroup_unlock().

Accessing a task's cgroup pointer may be done in the following ways:

- inside an rcu_read_lock() section via rcu_dereference()

3.3 Subsystem API

--------------------------

-----------------

Each subsystem should:

methods are create/destroy. Any others that are null are presumed to

be successful no-ops.

struct cgroup_subsys_state *create(struct cgroup *cont)

struct cgroup_subsys_state *create(struct cgroup_subsys *ss,

				   struct cgroup *cgrp)

(cgroup_mutex held by caller)

Called to create a subsystem state object for a cgroup. The

it's the root of the hierarchy) and may be an appropriate place for

initialization code.

void destroy(struct cgroup *cont)

void destroy(struct cgroup_subsys *ss, struct cgroup *cgrp)

(cgroup_mutex held by caller)

The cgroup system is about to destroy the passed cgroup; the subsystem

newly-created cgroup if an error occurs after this subsystem's

create() method has been called for the new cgroup).

int can_attach(struct cgroup_subsys *ss, struct cgroup *cont,

void pre_destroy(struct cgroup_subsys *ss, struct cgroup *cgrp);

(cgroup_mutex held by caller)

Called before checking the reference count on each subsystem. This may

be useful for subsystems which have some extra references even if

there are not tasks in the cgroup.

int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,

	       struct task_struct *task)

(cgroup_mutex held by caller)

called on a fork. If this method returns 0 (success) then this should

remain valid while the caller holds cgroup_mutex.

void attach(struct cgroup_subsys *ss, struct cgroup *cont,

	    struct cgroup *old_cont, struct task_struct *task)

void attach(struct cgroup_subsys *ss, struct cgroup *cgrp,

	    struct cgroup *old_cgrp, struct task_struct *task)

Called after the task has been attached to the cgroup, to allow any

post-attachment activity that requires memory allocations or blocking.

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

Called during task exit

Called during task exit.

int populate(struct cgroup_subsys *ss, struct cgroup *cont)

int populate(struct cgroup_subsys *ss, struct cgroup *cgrp)

Called after creation of a cgroup to allow a subsystem to populate

the cgroup directory with file entries.  The subsystem should make

method can return an error code, the error code is currently not

always handled well.

void post_clone(struct cgroup_subsys *ss, struct cgroup *cont)

void post_clone(struct cgroup_subsys *ss, struct cgroup *cgrp)

Called at the end of cgroup_clone() to do any paramater

initialization which might be required before a task could attach.  For

mega or gigabytes.

# cat /cgroups/0/memory.limit_in_bytes

4194304 Bytes

4194304

NOTE: The interface has now changed to display the usage in bytes

instead of pages

We can check the usage:

# cat /cgroups/0/memory.usage_in_bytes

1216512 Bytes

1216512

A successful write to this file does not guarantee a successful set of

this limit to the value written into the file.  This can be due to a

# echo -n 1 > memory.limit_in_bytes

# cat memory.limit_in_bytes

4096 Bytes

4096

The memory.failcnt field gives the number of times that the cgroup limit was

exceeded.

tasks have migrated away from it. Such charges are automatically dropped at

rmdir() if there are no tasks.

4.4 Choosing what to account  -- Page Cache (unmapped) vs RSS (mapped)?

The type of memory accounted by the cgroup can be limited to just

mapped pages by writing "1" to memory.control_type field

echo -n 1 > memory.control_type

5. TODO

1. Add support for accounting huge pages (as a separate controller)

3. Emelianov, Pavel. Resource controllers based on process cgroups

   http://lkml.org/lkml/2007/3/6/198

4. Emelianov, Pavel. RSS controller based on process cgroups (v2)

   http://lkml.org/lkml/2007/4/9/74

   http://lkml.org/lkml/2007/4/9/78

5. Emelianov, Pavel. RSS controller based on process cgroups (v3)

   http://lkml.org/lkml/2007/5/30/244

6. Menage, Paul. Control Groups v10, http://lwn.net/Articles/236032/

7. Vaidyanathan, Srinivasan, Control Groups: Pagecache accounting and control

   subsystem (v3), http://lwn.net/Articles/235534/

8. Singh, Balbir. RSS controller V2 test results (lmbench),

8. Singh, Balbir. RSS controller v2 test results (lmbench),

   http://lkml.org/lkml/2007/5/17/232

9. Singh, Balbir. RSS controller V2 AIM9 results

9. Singh, Balbir. RSS controller v2 AIM9 results

   http://lkml.org/lkml/2007/5/18/1

10. Singh, Balbir. Memory controller v6 results,

10. Singh, Balbir. Memory controller v6 test results,

    http://lkml.org/lkml/2007/8/19/36

11. Singh, Balbir. Memory controller v6, http://lkml.org/lkml/2007/8/17/69

11. Singh, Balbir. Memory controller introduction (v6),

    http://lkml.org/lkml/2007/8/17/69

12. Corbet, Jonathan, Controlling memory use in cgroups,

    http://lwn.net/Articles/243795/

The cpus and mems files in the root (top_cpuset) cpuset are

read-only.  The cpus file automatically tracks the value of

cpu_online_map using a CPU hotplug notifier, and the mems file

automatically tracks the value of node_states[N_MEMORY]--i.e.,

automatically tracks the value of node_states[N_HIGH_MEMORY]--i.e.,

nodes with memory--using the cpuset_track_online_nodes() hook.

Drivers

-------

The OHCI-1394 drivers in drivers/firewire and drivers/ieee1394 initialize

the OHCI-1394 controllers to a working state and can be used to enable

physical DMA. By default you only have to load the driver, and physical

DMA access will be granted to all remote nodes, but it can be turned off

when using the ohci1394 driver.

Because these drivers depend on the PCI enumeration to be completed, an

initialization routine which can runs pretty early (long before console_init(),

The ohci1394 driver in drivers/ieee1394 initializes the OHCI-1394 controllers

to a working state and enables physical DMA by default for all remote nodes.

This can be turned off by ohci1394's module parameter phys_dma=0.

The alternative firewire-ohci driver in drivers/firewire uses filtered physical

DMA, hence is not yet suitable for remote debugging.

Because ohci1394 depends on the PCI enumeration to be completed, an

initialization routine which runs pretty early (long before console_init()

which makes the printk buffer appear on the console can be called) was written.

To activate it, enable CONFIG_PROVIDE_OHCI1394_DMA_INIT (Kernel hacking menu: