Merge branch 'dma-debug' of...

*.html

*.9.gz

*.9

*.aux

*.dvi

*.log

*.out

To mount a cgroup hierarchy with just the cpuset and numtasks

subsystems, type:

# mount -t cgroup -o cpuset,numtasks hier1 /dev/cgroup

# mount -t cgroup -o cpuset,memory hier1 /dev/cgroup

To change the set of subsystems bound to a mounted hierarchy, just

remount with different options:

# mount -o remount,cpuset,ns hier1 /dev/cgroup

# mount -o remount,cpuset,ns  /dev/cgroup

Now memory is removed from the hierarchy and ns is added.

Note this will add ns to the hierarchy but won't remove memory or

cpuset, because the new options are appended to the old ones:

# mount -o remount,ns /dev/cgroup

To Specify a hierarchy's release_agent:

# mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \

  xxx /dev/cgroup

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

Note that changing the set of subsystems is currently only supported

when the hierarchy consists of a single (root) cgroup. Supporting

tree of the cgroups in the system. For instance, /dev/cgroup

is the cgroup that holds the whole system.

If you want to change the value of release_agent:

# echo "/sbin/new_release_agent" > /dev/cgroup/release_agent

It can also be changed via remount.

If you want to create a new cgroup under /dev/cgroup:

# cd /dev/cgroup

# mkdir my_cgroup

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

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

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

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

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.

there are not tasks in the cgroup. If pre_destroy() returns error code,

rmdir() will fail with it. From this behavior, pre_destroy() can be

called multiple times against a cgroup.

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

	       struct task_struct *task)

Memory Resource Controller(Memcg)  Implementation Memo.

Last Updated: 2009/1/19

Last Updated: 2009/1/20

Base Kernel Version: based on 2.6.29-rc2.

Because VM is getting complex (one of reasons is memcg...), memcg's behavior

	# kill malloc task.

	Of course, tmpfs v.s. swapoff test should be tested, too.

 9.8 OOM-Killer

	Out-of-memory caused by memcg's limit will kill tasks under

	the memcg. When hierarchy is used, a task under hierarchy

	will be killed by the kernel.

	In this case, panic_on_oom shouldn't be invoked and tasks

	in other groups shouldn't be killed.

	It's not difficult to cause OOM under memcg as following.

	Case A) when you can swapoff

	#swapoff -a

	#echo 50M > /memory.limit_in_bytes

	run 51M of malloc

	Case B) when you use mem+swap limitation.

	#echo 50M > memory.limit_in_bytes

	#echo 50M > memory.memsw.limit_in_bytes

	run 51M of malloc

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

What:	GPIO autorequest on gpio_direction_{input,output}() in gpiolib

When:	February 2010

Why:	All callers should use explicit gpio_request()/gpio_free().

	The autorequest mechanism in gpiolib was provided mostly as a

	migration aid for legacy GPIO interfaces (for SOC based GPIOs).

	Those users have now largely migrated.  Platforms implementing

	the GPIO interfaces without using gpiolib will see no changes.

Who:	David Brownell <dbrownell@users.sourceforge.net>

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

What:	b43 support for firmware revision < 410

When:	The schedule was July 2008, but it was decided that we are going to keep the

        code as long as there are no major maintanance headaches.