---

yaml
---
r: 139867
b: refs/heads/master
c: d8881cd
h: refs/heads/master
i:
  139865: 5d3a4e3
  139863: 0e62cf4
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 8fe74cf053de7ad2124a894996f84fa890a81093
+refs/heads/master: d8881cdab5e1810b0a03b480ed16c1e761e68257

trunk/Documentation/DocBook/.gitignore

@@ -4,7 +4,3 @@
 *.html
 *.9.gz
 *.9
-*.aux
-*.dvi
-*.log
-*.out

trunk/Documentation/cgroups/cgroups.txt

@@ -333,23 +333,12 @@ The "xxx" is not interpreted by the cgroup code, but will appear in
 
 To mount a cgroup hierarchy with just the cpuset and numtasks
 subsystems, type:
-# mount -t cgroup -o cpuset,memory hier1 /dev/cgroup
+# mount -t cgroup -o cpuset,numtasks 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
 
-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.
+# mount -o remount,cpuset,ns  /dev/cgroup
 
 Note that changing the set of subsystems is currently only supported
 when the hierarchy consists of a single (root) cgroup. Supporting
@@ -360,11 +349,6 @@ Then under /dev/cgroup you can find a tree that corresponds to the
 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
@@ -492,13 +476,11 @@ cgroup->parent is still valid. (Note - can also be called for a
 newly-created cgroup if an error occurs after this subsystem's
 create() method has been called for the new cgroup).
 
-int pre_destroy(struct cgroup_subsys *ss, struct cgroup *cgrp);
+void 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. If pre_destroy() returns error code,
-rmdir() will fail with it. From this behavior, pre_destroy() can be
-called multiple times against a cgroup.
+there are not tasks in the cgroup.
 
 int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
 	       struct task_struct *task)

trunk/Documentation/cgroups/memcg_test.txt

@@ -1,5 +1,5 @@
 Memory Resource Controller(Memcg)  Implementation Memo.
-Last Updated: 2009/1/20
+Last Updated: 2009/1/19
 Base Kernel Version: based on 2.6.29-rc2.
 
 Because VM is getting complex (one of reasons is memcg...), memcg's behavior
@@ -360,21 +360,3 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
 	# 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

trunk/Documentation/feature-removal-schedule.txt

@@ -255,16 +255,6 @@ Who:	Jan Engelhardt <jengelh@computergmbh.de>
 
 ---------------------------
 
-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.