* linux-next: manual merge of the akpm tree with the cgroup tree
@ 2015-12-21 7:13 Stephen Rothwell
0 siblings, 0 replies; 7+ messages in thread
From: Stephen Rothwell @ 2015-12-21 7:13 UTC (permalink / raw)
To: Andrew Morton, Tejun Heo; +Cc: linux-next, linux-kernel, Johannes Weiner
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* linux-next: manual merge of the akpm tree with the cgroup tree
@ 2012-11-06 4:58 Stephen Rothwell
0 siblings, 0 replies; 7+ messages in thread
From: Stephen Rothwell @ 2012-11-06 4:58 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Tejun Heo, Glauber Costa, Michal Hocko
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* linux-next: manual merge of the akpm tree with the cgroup tree
@ 2012-11-06 4:51 Stephen Rothwell
0 siblings, 0 replies; 7+ messages in thread
From: Stephen Rothwell @ 2012-11-06 4:51 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Glauber Costa, Michal Hocko, Tejun Heo
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the cgroup tree
2011-12-14 18:08 ` Andrew Morton
@ 2011-12-14 18:11 ` Frederic Weisbecker
0 siblings, 0 replies; 7+ messages in thread
From: Frederic Weisbecker @ 2011-12-14 18:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: Stephen Rothwell, linux-next, linux-kernel, Tejun Heo
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the cgroup tree
2011-12-14 16:16 ` Frederic Weisbecker
@ 2011-12-14 18:08 ` Andrew Morton
2011-12-14 18:11 ` Frederic Weisbecker
0 siblings, 1 reply; 7+ messages in thread
From: Andrew Morton @ 2011-12-14 18:08 UTC (permalink / raw)
To: Frederic Weisbecker; +Cc: Stephen Rothwell, linux-next, linux-kernel, Tejun Heo
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: linux-next: manual merge of the akpm tree with the cgroup tree
2011-12-14 6:51 Stephen Rothwell
@ 2011-12-14 16:16 ` Frederic Weisbecker
2011-12-14 18:08 ` Andrew Morton
0 siblings, 1 reply; 7+ messages in thread
From: Frederic Weisbecker @ 2011-12-14 16:16 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel, Tejun Heo
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* linux-next: manual merge of the akpm tree with the cgroup tree
@ 2011-12-14 6:51 Stephen Rothwell
2011-12-14 16:16 ` Frederic Weisbecker
0 siblings, 1 reply; 7+ messages in thread
From: Stephen Rothwell @ 2011-12-14 6:51 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-next, linux-kernel, Tejun Heo, Frederic Weisbecker
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-12-21 7:13 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-21 7:13 linux-next: manual merge of the akpm tree with the cgroup tree Stephen Rothwell
-- strict thread matches above, loose matches on Subject: below --
2012-11-06 4:58 Stephen Rothwell
2012-11-06 4:51 Stephen Rothwell
2011-12-14 6:51 Stephen Rothwell
2011-12-14 16:16 ` Frederic Weisbecker
2011-12-14 18:08 ` Andrew Morton
2011-12-14 18:11 ` Frederic Weisbecker
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).