linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.cz>
To: Tejun Heo <tj@kernel.org>, Andrew Morton <akpm@linux-foundation.org>
Cc: sfr@canb.auug.org.au, linux-next@vger.kernel.org,
	Johannes Weiner <hannes@cmpxchg.org>,
	Balbir Singh <bsingharora@gmail.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	cgroups@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [HEADSUP] conflicts between cgroup/for-3.12 and memcg
Date: Fri, 9 Aug 2013 09:22:07 +0200	[thread overview]
Message-ID: <20130809072207.GA16531@dhcp22.suse.cz> (raw)
In-Reply-To: <20130809003402.GC13427@mtj.dyndns.org>

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

On Thu 08-08-13 20:34:02, Tejun Heo wrote:
> Hello, Stephen, Andrew.
> 
> I just applied rather invasive API update to cgroup/for-3.12, which
> led to conflicts in two files - include/net/netprio_cgroup.h and
> mm/memcontrol.c.  The former is trivial context conflict and the two
> changes conflicting are independent.  The latter contains several
> conflicts and unfortunately isn't trivial, especially the iterator
> update and the memcg patches should probably be rebased.
> 
> I can hold back pushing for-3.12 into for-next until the memcg patches
> are rebased.  Would that work?

I have just tried to merge cgroups/for-3.12 into my memcg tree and there
were some conflicts indeed. They are attached for reference. The
resolving is trivial. I've just picked up HEAD as all the conflicts are
for added resp. removed code in mmotm.

Andrew, let me know if you need a help with rebasing.

HTH
-- 
Michal Hocko
SUSE Labs

[-- Attachment #2: memcontrol.conflicts --]
[-- Type: text/plain, Size: 2110 bytes --]

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index b73988a..c208154 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -182,6 +182,29 @@ struct mem_cgroup_per_node {
 	struct mem_cgroup_per_zone zoneinfo[MAX_NR_ZONES];
 };
 
+<<<<<<< HEAD
+=======
+/*
+ * Cgroups above their limits are maintained in a RB-Tree, independent of
+ * their hierarchy representation
+ */
+
+struct mem_cgroup_tree_per_zone {
+	struct rb_root rb_root;
+	spinlock_t lock;
+};
+
+struct mem_cgroup_tree_per_node {
+	struct mem_cgroup_tree_per_zone rb_tree_per_zone[MAX_NR_ZONES];
+};
+
+struct mem_cgroup_tree {
+	struct mem_cgroup_tree_per_node *rb_tree_per_node[MAX_NUMNODES];
+};
+
+static struct mem_cgroup_tree soft_limit_tree __read_mostly;
+
+>>>>>>> tj-cgroups/for-3.12
 struct mem_cgroup_threshold {
 	struct eventfd_ctx *eventfd;
 	u64 threshold;
@@ -255,7 +278,10 @@ struct mem_cgroup {
 
 	bool		oom_lock;
 	atomic_t	under_oom;
+<<<<<<< HEAD
 	atomic_t	oom_wakeups;
+=======
+>>>>>>> tj-cgroups/for-3.12
 
 	int	swappiness;
 	/* OOM-Killer disable */
@@ -323,6 +349,7 @@ struct mem_cgroup {
 	 */
 	spinlock_t soft_lock;
 
+<<<<<<< HEAD
 	/*
 	 * If true then this group has increased parents' children_in_excess
 	 * when it got over the soft limit.
@@ -334,6 +361,8 @@ struct mem_cgroup {
 	/* Number of children that are in soft limit excess */
 	atomic_t children_in_excess;
 
+=======
+>>>>>>> tj-cgroups/for-3.12
 	struct mem_cgroup_per_node *nodeinfo[0];
 	/* WARNING: nodeinfo must be the last member here */
 };
@@ -3573,9 +3602,15 @@ __memcg_kmem_newpage_charge(gfp_t gfp, struct mem_cgroup **_memcg, int order)
 	 * the page allocator. Therefore, the following sequence when backed by
 	 * the SLUB allocator:
 	 *
+<<<<<<< HEAD
 	 *	memcg_stop_kmem_account();
 	 *	kmalloc(<large_number>)
 	 *	memcg_resume_kmem_account();
+=======
+	 * 	memcg_stop_kmem_account();
+	 * 	kmalloc(<large_number>)
+	 * 	memcg_resume_kmem_account();
+>>>>>>> tj-cgroups/for-3.12
 	 *
 	 * would effectively ignore the fact that we should skip accounting,
 	 * since it will drive us directly to this function without passing

  reply	other threads:[~2013-08-09  7:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-09  0:34 [HEADSUP] conflicts between cgroup/for-3.12 and memcg Tejun Heo
2013-08-09  7:22 ` Michal Hocko [this message]
2013-08-09 14:19   ` Tejun Heo
2013-08-09 15:47     ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130809072207.GA16531@dhcp22.suse.cz \
    --to=mhocko@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=bsingharora@gmail.com \
    --cc=cgroups@vger.kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-mm@kvack.org \
    --cc=linux-next@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).