linux-next: manual merge of the akpm tree with the cgroup tree

linux-next: manual merge of the akpm tree with the cgroup tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]

Hi Andrew,

Today's linux-next merge of the akpme tree got conflicts in several files
between commits from the cgroup  tree and commit "cgroups: add previous
cgroup in can_attach_task/attach_task callbacks" from the akpm tree.

This got a bit to hard to resolve, so I dropped that patch and the
following from the akpm tree.

cgroups: new cancel_attach_task() subsystem callback
cgroups: ability to stop res charge propagation on bounded ancestor
cgroups: add res counter common ancestor searching
res_counter: allow charge failure pointer to be null
cgroups: pull up res counter charge failure interpretation to caller
cgroups: allow subsystems to cancel a fork
cgroups: add a task counter subsystem
cgroups: ERR_PTR needs err.h
cgroup: Fix task counter common ancestor logic
cgroup-fix-task-counter-common-ancestor-logic-checkpatch-fixes

I am wondering if that patch set should be included in the cgroup tree?
Alternatively, you could provide me with a new set of patches based on
today's linux-next.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the akpm tree with the cgroup tree

[Frederic Weisbecker]

On Wed, Dec 14, 2011 at 05:51:01PM +1100, Stephen Rothwell wrote:
> Hi Andrew,
> 
> Today's linux-next merge of the akpme tree got conflicts in several files
> between commits from the cgroup  tree and commit "cgroups: add previous
> cgroup in can_attach_task/attach_task callbacks" from the akpm tree.
> 
> This got a bit to hard to resolve, so I dropped that patch and the
> following from the akpm tree.

Yeah there are many things I need to update to get a clean rebase.

> 
> cgroups: new cancel_attach_task() subsystem callback
> cgroups: ability to stop res charge propagation on bounded ancestor
> cgroups: add res counter common ancestor searching
> res_counter: allow charge failure pointer to be null
> cgroups: pull up res counter charge failure interpretation to caller
> cgroups: allow subsystems to cancel a fork
> cgroups: add a task counter subsystem
> cgroups: ERR_PTR needs err.h
> cgroup: Fix task counter common ancestor logic
> cgroup-fix-task-counter-common-ancestor-logic-checkpatch-fixes
> 
> I am wondering if that patch set should be included in the cgroup tree?

That would be probably the easier solution.
Andrew, do you mind if I rebase these patches and target them to Tejun's
tree instead? We can keep them on a standalone branch there based on Tejuns until
we reach an agreement on their upstreamability.

Re: linux-next: manual merge of the akpm tree with the cgroup tree

[Andrew Morton]

On Wed, 14 Dec 2011 17:16:31 +0100 Frederic Weisbecker <fweisbec@gmail.com> wrote:

> > 
> > cgroups: new cancel_attach_task() subsystem callback
> > cgroups: ability to stop res charge propagation on bounded ancestor
> > cgroups: add res counter common ancestor searching
> > res_counter: allow charge failure pointer to be null
> > cgroups: pull up res counter charge failure interpretation to caller
> > cgroups: allow subsystems to cancel a fork
> > cgroups: add a task counter subsystem
> > cgroups: ERR_PTR needs err.h
> > cgroup: Fix task counter common ancestor logic
> > cgroup-fix-task-counter-common-ancestor-logic-checkpatch-fixes
> > 
> > I am wondering if that patch set should be included in the cgroup tree?
> 
> That would be probably the easier solution.
> Andrew, do you mind if I rebase these patches and target them to Tejun's
> tree instead?

Sure, that works,  I'll drop them.

> We can keep them on a standalone branch there based on Tejuns until
> we reach an agreement on their upstreamability.

I wondered what had been happening with that discussion.  I guess we
need to restart it.

Re: linux-next: manual merge of the akpm tree with the cgroup tree

[Frederic Weisbecker]

On Wed, Dec 14, 2011 at 10:08:51AM -0800, Andrew Morton wrote:
> On Wed, 14 Dec 2011 17:16:31 +0100 Frederic Weisbecker <fweisbec@gmail.com> wrote:
> 
> > > 
> > > cgroups: new cancel_attach_task() subsystem callback
> > > cgroups: ability to stop res charge propagation on bounded ancestor
> > > cgroups: add res counter common ancestor searching
> > > res_counter: allow charge failure pointer to be null
> > > cgroups: pull up res counter charge failure interpretation to caller
> > > cgroups: allow subsystems to cancel a fork
> > > cgroups: add a task counter subsystem
> > > cgroups: ERR_PTR needs err.h
> > > cgroup: Fix task counter common ancestor logic
> > > cgroup-fix-task-counter-common-ancestor-logic-checkpatch-fixes
> > > 
> > > I am wondering if that patch set should be included in the cgroup tree?
> > 
> > That would be probably the easier solution.
> > Andrew, do you mind if I rebase these patches and target them to Tejun's
> > tree instead?
> 
> Sure, that works,  I'll drop them.

Cool.

> > We can keep them on a standalone branch there based on Tejuns until
> > we reach an agreement on their upstreamability.
> 
> I wondered what had been happening with that discussion.  I guess we
> need to restart it.
> 

Dan J Walsh and Daniel Berrange who work on lxc and for whom I'm primarily
working on this feature have added their point of view. You might want to
have a look.

I can post something that synthetize everybody's words.

linux-next: manual merge of the akpm tree with the cgroup tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
mm/memcontrol.c between commit ab5196c202c6 ("memcg: make
mem_cgroup_reparent_charges non failing") from the cgroup tree and commit
"memcg: allow a memcg with kmem charges to be destructed" from the akpm
tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc mm/memcontrol.c
index 8f2b789,540bac5..0000000
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@@ -3987,11 -4015,15 +3992,12 @@@ static void mem_cgroup_force_empty_list
   *
   * Caller is responsible for holding css reference on the memcg.
   */
 -static int mem_cgroup_reparent_charges(struct mem_cgroup *memcg)
 +static void mem_cgroup_reparent_charges(struct mem_cgroup *memcg)
  {
 -	struct cgroup *cgrp = memcg->css.cgroup;
  	int node, zid;
+ 	u64 usage;
  
  	do {
 -		if (cgroup_task_count(cgrp) || !list_empty(&cgrp->children))
 -			return -EBUSY;
  		/* This is for making all *used* pages to be on LRU. */
  		lru_add_drain_all();
  		drain_all_stock_sync(memcg);
@@@ -4016,7 -4053,11 +4027,9 @@@
  		 * right after the check. RES_USAGE should be safe as we always
  		 * charge before adding to the LRU.
  		 */
- 	} while (res_counter_read_u64(&memcg->res, RES_USAGE) > 0);
+ 		usage = res_counter_read_u64(&memcg->res, RES_USAGE) -
+ 			res_counter_read_u64(&memcg->kmem, RES_USAGE);
+ 	} while (usage > 0);
 -
 -	return 0;
  }
  
  /*

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the cgroup tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1074 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
mm/memcontrol.c between commit ab5196c202c6 ("memcg: make
mem_cgroup_reparent_charges non failing") from the cgroup tree and commit
"memcg: destroy memcg caches" from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc mm/memcontrol.c
index a38e9fb,b650e09..0000000
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@@ -5946,11 -6034,17 +6008,12 @@@ free_out
  	return ERR_PTR(error);
  }
  
 -static int mem_cgroup_pre_destroy(struct cgroup *cont)
 +static void mem_cgroup_pre_destroy(struct cgroup *cont)
  {
  	struct mem_cgroup *memcg = mem_cgroup_from_cont(cont);
 -	int ret;
  
 -	css_get(&memcg->css);
 -	ret = mem_cgroup_reparent_charges(memcg);
 +	mem_cgroup_reparent_charges(memcg);
+ 	mem_cgroup_destroy_all_caches(memcg);
 -	css_put(&memcg->css);
 -
 -	return ret;
  }
  
  static void mem_cgroup_destroy(struct cgroup *cont)

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the cgroup tree

[Stephen Rothwell]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in:

  init/Kconfig

between commit:

  6bf024e69333 ("cgroup: put controller Kconfig options in meaningful order")

from the cgroup tree and commit:

  "mm: memcontrol: introduce CONFIG_MEMCG_LEGACY_KMEM"

from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc init/Kconfig
index faa4d087d69e,8185e8de04a1..000000000000
--- a/init/Kconfig
+++ b/init/Kconfig
@@@ -1010,43 -1072,39 +1013,48 @@@ config MEMCG_KME
  	  the kmem extension can use it to guarantee that no group of processes
  	  will ever exhaust kernel resources alone.
  
+ 	  This option affects the ORIGINAL cgroup interface. The cgroup2 memory
+ 	  controller includes important in-kernel memory consumers per default.
+ 
+ 	  If you're using cgroup2, say N.
+ 
 -config CGROUP_HUGETLB
 -	bool "HugeTLB Resource Controller for Control Groups"
 -	depends on HUGETLB_PAGE
 -	select PAGE_COUNTER
 +config BLK_CGROUP
 +	bool "IO controller"
 +	depends on BLOCK
  	default n
 -	help
 -	  Provides a cgroup Resource Controller for HugeTLB pages.
 -	  When you enable this, you can put a per cgroup limit on HugeTLB usage.
 -	  The limit is enforced during page fault. Since HugeTLB doesn't
 -	  support page reclaim, enforcing the limit at page fault time implies
 -	  that, the application will get SIGBUS signal if it tries to access
 -	  HugeTLB pages beyond its limit. This requires the application to know
 -	  beforehand how much HugeTLB pages it would require for its use. The
 -	  control group is tracked in the third page lru pointer. This means
 -	  that we cannot use the controller with huge page less than 3 pages.
 +	---help---
 +	Generic block IO controller cgroup interface. This is the common
 +	cgroup interface which should be used by various IO controlling
 +	policies.
  
 -config CGROUP_PERF
 -	bool "Enable perf_event per-cpu per-container group (cgroup) monitoring"
 -	depends on PERF_EVENTS && CGROUPS
 -	help
 -	  This option extends the per-cpu mode to restrict monitoring to
 -	  threads which belong to the cgroup specified and run on the
 -	  designated cpu.
 +	Currently, CFQ IO scheduler uses it to recognize task groups and
 +	control disk bandwidth allocation (proportional time slice allocation)
 +	to such task groups. It is also used by bio throttling logic in
 +	block layer to implement upper limit in IO rates on a device.
  
 -	  Say N if unsure.
 +	This option only enables generic Block IO controller infrastructure.
 +	One needs to also enable actual IO controlling logic/policy. For
 +	enabling proportional weight division of disk bandwidth in CFQ, set
 +	CONFIG_CFQ_GROUP_IOSCHED=y; for enabling throttling policy, set
 +	CONFIG_BLK_DEV_THROTTLING=y.
 +
 +	See Documentation/cgroups/blkio-controller.txt for more information.
 +
 +config DEBUG_BLK_CGROUP
 +	bool "IO controller debugging"
 +	depends on BLK_CGROUP
 +	default n
 +	---help---
 +	Enable some debugging help. Currently it exports additional stat
 +	files in a cgroup which can be useful for debugging.
 +
 +config CGROUP_WRITEBACK
 +	bool
 +	depends on MEMCG && BLK_CGROUP
 +	default y
  
  menuconfig CGROUP_SCHED
 -	bool "Group CPU scheduler"
 +	bool "CPU controller"
  	default n
  	help
  	  This feature lets CPU scheduler recognize task groups and control CPU
t