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

2015-12-20 Thread 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 Rothwells...@canb.auug.org.au

diff --cc init/Kconfig
index faa4d087d69e,8185e8de04a1..
--- 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

2012-11-05 Thread Stephen Rothwell 
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 Rothwells...@canb.auug.org.au

diff --cc mm/memcontrol.c
index a38e9fb,b650e09..000
--- 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)


pgpISPTKAMBAu.pgp
Description: PGP signature

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

2012-11-05 Thread Stephen Rothwell 
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 Rothwells...@canb.auug.org.au

diff --cc mm/memcontrol.c
index 8f2b789,540bac5..000
--- 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;
  }
  
  /*


pgpCs5HP31Ay8.pgp
Description: PGP signature