Memory controller add mm->owner

--- linux-2.6.25-rc5/include/linux/mm_types.h~memory-controller-add-mm-owner 2008-03-20 13:35:09.000000000 +0530
+++ linux-2.6.25-rc5-balbir/include/linux/mm_types.h 2008-03-20 15:11:05.000000000 +0530

 @@ -228,7 +228,10 @@ struct mm_struct {
        rwlock_t                ioctx_list_lock;
        struct kioctx           *ioctx_list;
  #ifdef CONFIG_CGROUP_MEM_RES_CTLR
 -       struct mem_cgroup *mem_cgroup;
 +       struct task_struct *owner;      /* The thread group leader that */
 +                                       /* owns the mm_struct. This     */
 +                                       /* might be useful even outside */
 +                                       /* of the config option         */

#endif

@@ -248,12 +248,40 @@ void mm_init_cgroup(struct mm_struct *mm

        mem = mem_cgroup_from_task(p);
        css_get(&mem->css);
 -       mm->mem_cgroup = mem;
 +       mm->owner = p;
 +}
 +
 +void mem_cgroup_fork_init(struct task_struct *p)
 +{
 +       struct mm_struct *mm = get_task_mm(p);
 +       struct mem_cgroup *mem, *oldmem;
 +       if (!mm)
 +               return;
 +
 +       /*
 +        * Initial owner at mm_init_cgroup() time is the task itself.
 +        * The thread group leader had not been setup then
 +        */
 +       oldmem = mem_cgroup_from_task(mm->owner);
 +       /*
 +        * Override the mm->owner after we know the thread group later
 +        */
 +       mm->owner = p->group_leader;
 +       mem = mem_cgroup_from_task(mm->owner);
 +       css_get(&mem->css);
 +       css_put(&oldmem->css);
 +       mmput(mm);

}

void mm_free_cgroup(struct mm_struct *mm)
{
- css_put(&mm->mem_cgroup->css);
+ struct mem_cgroup *mem;
+
+ /*
+ * TODO: Should we assign mm->owner to NULL here?
+ */
+ mem = mem_cgroup_from_task(mm->owner);
+ css_put(&mem->css);
}

 -       rcu_read_lock();
 -       mem = rcu_dereference(mm->mem_cgroup);
 +       mem = mem_cgroup_from_task(mm->owner);

@@ -1069,7 +1096,6 @@ static void mem_cgroup_move_task(struct

                goto out;

        css_get(&mem->css);
 -       rcu_assign_pointer(mm->mem_cgroup, mem);
        css_put(&old_mem->css);

Quoted 11 lines · Balbir Singh

--- linux-2.6.25-rc5/include/linux/mm_types.h~memory-controller-add-mm-owner 2008-03-20 13:35:09.000000000 +0530
+++ linux-2.6.25-rc5-balbir/include/linux/mm_types.h 2008-03-20 15:11:05.000000000 +0530

 @@ -228,7 +228,10 @@ struct mm_struct {
        rwlock_t                ioctx_list_lock;
        struct kioctx           *ioctx_list;
  #ifdef CONFIG_CGROUP_MEM_RES_CTLR
 -       struct mem_cgroup *mem_cgroup;
 +       struct task_struct *owner;      /* The thread group leader that */
 +                                       /* owns the mm_struct. This     */
 +                                       /* might be useful even outside */
 +                                       /* of the config option         */

Quoted 1 line

#endif

This should probably be controlled by something like a CONFIG_MM_OWNER that's selected by any Kconfig option (mem cgroup, etc) that needs mm->owner to be maintained.

Quoted 30 lines

@@ -248,12 +248,40 @@ void mm_init_cgroup(struct mm_struct *mm

        mem = mem_cgroup_from_task(p);
        css_get(&mem->css);
 -       mm->mem_cgroup = mem;
 +       mm->owner = p;
 +}
 +
 +void mem_cgroup_fork_init(struct task_struct *p)
 +{
 +       struct mm_struct *mm = get_task_mm(p);
 +       struct mem_cgroup *mem, *oldmem;
 +       if (!mm)
 +               return;
 +
 +       /*
 +        * Initial owner at mm_init_cgroup() time is the task itself.
 +        * The thread group leader had not been setup then
 +        */
 +       oldmem = mem_cgroup_from_task(mm->owner);
 +       /*
 +        * Override the mm->owner after we know the thread group later
 +        */
 +       mm->owner = p->group_leader;
 +       mem = mem_cgroup_from_task(mm->owner);
 +       css_get(&mem->css);
 +       css_put(&oldmem->css);
 +       mmput(mm);

}

Quoted 11 lines

void mm_free_cgroup(struct mm_struct *mm)
{
- css_put(&mm->mem_cgroup->css);
+ struct mem_cgroup *mem;
+
+ /*
+ * TODO: Should we assign mm->owner to NULL here?
+ */
+ mem = mem_cgroup_from_task(mm->owner);
+ css_put(&mem->css);
}

It seems to me that the code to setup/maintain mm->owner should be independent of the control groups, but should be part of the generic fork/exit code.

Also, if mm->owner exits but mm is still alive (unlikely, but could happen with weird custom threading libraries?) then we need to reassign mm->owner to one of the other users of the mm (by looking first in the thread group, then among the parents/siblings/children, and then among all processes as a last resort?)

Quoted 3 lines

 -       rcu_read_lock();
 -       mem = rcu_dereference(mm->mem_cgroup);
 +       mem = mem_cgroup_from_task(mm->owner);

I think we still need the rcu_read_lock(), since mm->owner can move cgroups any time.

Quoted 7 lines

@@ -1069,7 +1096,6 @@ static void mem_cgroup_move_task(struct

                goto out;

        css_get(&mem->css);
 -       rcu_assign_pointer(mm->mem_cgroup, mem);
        css_put(&old_mem->css);

We shouldn't need reference counting on this pointer, since the cgroups framework won't allow a subsystem to be freed while it has any tasks in it.

Quoted 6 lines

Also, if mm->owner exits but mm is still alive (unlikely, but could happen with weird custom threading libraries?) then we need to reassign mm->owner to one of the other users of the mm (by looking first in the thread group, then among the parents/siblings/children, and then among all processes as a last resort?)

The comment in __exit_signal states that

"The group leader stays around as a zombie as long
as there are other threads. When it gets reaped, the exit.c code will add its counts into these totals."

Given that the thread group leader stays around, do we need to reassign mm->owner? Do you do anything special in cgroups like cleanup the task_struct->css->subsys_state on exit?

Quoted 5 lines

Quoted 4 lines

 -       rcu_read_lock();
 -       mem = rcu_dereference(mm->mem_cgroup);
 +       mem = mem_cgroup_from_task(mm->owner);

Quoted 3 lines

I think we still need the rcu_read_lock(), since mm->owner can move cgroups any time.

OK, so cgroup task movement is protected by RCU, right? I'll check for all mm->owner uses.

Quoted 7 lines · Balbir Singh

Quoted 6 lines

Also, if mm->owner exits but mm is still alive (unlikely, but could happen with weird custom threading libraries?) then we need to reassign mm->owner to one of the other users of the mm (by looking first in the thread group, then among the parents/siblings/children, and then among all processes as a last resort?)

Quoted 5 lines

The comment in __exit_signal states that

"The group leader stays around as a zombie as long
as there are other threads. When it gets reaped, the exit.c code will add its counts into these totals."

Ah, that's useful to know.

Quoted 4 lines

Given that the thread group leader stays around, do we need to reassign mm->owner? Do you do anything special in cgroups like cleanup the task_struct->css->subsys_state on exit?

OK, so we don't need to handle this for NPTL apps - but for anything still using LinuxThreads or manually constructed clone() calls that use CLONE_VM without CLONE_PID, this could still be an issue.

guess there's the case of someone holding a reference to the mm via a /proc file?)

Quoted 11 lines

Quoted 7 lines

Quoted 3 lines

 -       rcu_read_lock();
 -       mem = rcu_dereference(mm->mem_cgroup);
 +       mem = mem_cgroup_from_task(mm->owner);

I think we still need the rcu_read_lock(), since mm->owner can move cgroups any time.

OK, so cgroup task movement is protected by RCU, right? I'll check for all mm->owner uses.

Yes - cgroup_attach() uses synchronize_rcu() before release the cgroup mutex. So although you can't guarantee that the cgroup set won't change if you're just using RCU, you can't guarantee that you're addressing a still-valid non-destroyed (and of course non-freed) cgroup set.

Quoted 3 lines

OK, so we don't need to handle this for NPTL apps - but for anything still using LinuxThreads or manually constructed clone() calls that use CLONE_VM without CLONE_PID, this could still be an issue.

CLONE_PID?? Do you mean CLONE_THREAD?

For the case you mentioned, mm->owner is a moving target and we don't want to spend time finding the successor, that can be expensive when threads start exiting one-by-one quickly and when the number of threads are high. I wonder if there is an efficient way to find mm->owner in that case.

Quoted 5 lines · Balbir Singh

Quoted 3 lines

OK, so we don't need to handle this for NPTL apps - but for anything still using LinuxThreads or manually constructed clone() calls that use CLONE_VM without CLONE_PID, this could still be an issue.

CLONE_PID?? Do you mean CLONE_THREAD?

Yes, sorry - CLONE_THREAD.

Quoted 5 lines

For the case you mentioned, mm->owner is a moving target and we don't want to spend time finding the successor, that can be expensive when threads start exiting one-by-one quickly and when the number of threads are high. I wonder if there is an efficient way to find mm->owner in that case.

But:

- running a high-threadcount LinuxThreads process is by definition inefficient and expensive (hence the move to NPTL)

- any potential performance hit is only paid at exit time

- in the normal case, any of your children or one of your siblings will be a suitable alternate owner

- in the worst case, it's not going to be worse than doing a for_each_thread() loop

so I don't think this would be a major problem

Quoted 19 lines · Paul Menage

Quoted 5 lines · Balbir Singh

Quoted 3 lines

OK, so we don't need to handle this for NPTL apps - but for anything still using LinuxThreads or manually constructed clone() calls that use CLONE_VM without CLONE_PID, this could still be an issue.

CLONE_PID?? Do you mean CLONE_THREAD?

Yes, sorry - CLONE_THREAD.

Quoted 5 lines

For the case you mentioned, mm->owner is a moving target and we don't want to spend time finding the successor, that can be expensive when threads start exiting one-by-one quickly and when the number of threads are high. I wonder if there is an efficient way to find mm->owner in that case.

But:

- running a high-threadcount LinuxThreads process is by definition inefficient and expensive (hence the move to NPTL)

Quoted 8 lines

- any potential performance hit is only paid at exit time

- in the normal case, any of your children or one of your siblings will be a suitable alternate owner

- in the worst case, it's not going to be worse than doing a for_each_thread() loop

Quoted 2 lines

so I don't think this would be a major problem

I've been looking at zap_threads, I suspect we'll end up implementing a similar loop, which makes me very uncomfortable. Adding code for the least possible scenario. It will not get invoked for CLONE_THREAD, but will get invoked for the case when CLONE_VM is set without CLONE_THREAD.

I'll try and experiment a bit more and see what I come up with

Quoted 4 lines

Quoted 4 lines

- in the worst case, it's not going to be worse than doing a for_each_thread() loop

This will have to be the common case, since you never know what combination of clone calls did CLONE_VM and what did CLONE_THREAD. At exit time, we need to pay a for_each_process() overhead.

Quoted 8 lines · Balbir Singh

Quoted 4 lines

Quoted 4 lines

- in the worst case, it's not going to be worse than doing a for_each_thread() loop

This will have to be the common case, since you never know what combination of clone calls did CLONE_VM and what did CLONE_THREAD. At exit time, we need to pay a for_each_process() overhead.

I'm not convinced of this. All we have to do is find some other process p where p->mm == current->mm and make it the new owner. Exactly what sequence of clone() calls was used to cause the sharing isn't really relevant. I really think that a suitable candidate will be found amongst your children or your first sibling in 99.9% of those cases where more than one process is using an mm.

Hmmm.. the 99.9% of the time is just guess work (not measured, could be possibly true). I see and understand your code below. But before I try and implement something like that, I was wondering why zap_threads() does not have that heuristic. That should explain my inhibition.

Can anyone elaborate on zap_threads further?

This patch removes the mem_cgroup member from mm_struct and instead adds an owner. This approach was suggested by Paul Menage. The advantage of this approach is that, once the mm->owner is known, using the subsystem id, the cgroup can be determined. It also allows several control groups that are virtually grouped by mm_struct, to exist independent of the memory controller i.e., without adding mem_cgroup's for each controller, to mm_struct.

The code initially assigns mm->owner to the task and then after the thread group leader is identified. The mm->owner is changed to the thread group leader of the task later at the end of copy_process.

Signed-off-by Balbir Singh <[email protected]>

---

 include/linux/memcontrol.h |   14 +++++++++++++-
 include/linux/mm_types.h   |    5 ++++-
 kernel/fork.c              |    4 ++++
 mm/memcontrol.c            |   42 ++++++++++++++++++++++++++++++++++--------
 4 files changed, 55 insertions(+), 10 deletions(-)

diff -puN include/linux/mm_types.h~memory-controller-add-mm-owner include/linux/mm_types.h

include/linux/mm_types.h renamed from include/linux/mm_types.h~memory-controller-add-mm-owner +4 -1

@@ -228,7 +228,10 @@ struct mm_struct {
 	rwlock_t		ioctx_list_lock;
 	struct kioctx		*ioctx_list;
 #ifdef CONFIG_CGROUP_MEM_RES_CTLR
-	struct mem_cgroup *mem_cgroup;
+	struct task_struct *owner;	/* The thread group leader that */
+					/* owns the mm_struct. This     */
+					/* might be useful even outside */
+					/* of the config option         */
 #endif
 
 #ifdef CONFIG_PROC_FS

diff -puN kernel/fork.c~memory-controller-add-mm-owner kernel/fork.c

kernel/fork.c renamed from kernel/fork.c~memory-controller-add-mm-owner +4 -0

@@ -1357,6 +1357,10 @@ static struct task_struct *copy_process(
 	write_unlock_irq(&tasklist_lock);
 	proc_fork_connector(p);
 	cgroup_post_fork(p);
+
+	if (!(clone_flags & CLONE_VM))
+		mem_cgroup_fork_init(p);
+
 	return p;
 
 bad_fork_free_pid:

diff -puN include/linux/memcontrol.h~memory-controller-add-mm-owner include/linux/memcontrol.h

include/linux/memcontrol.h renamed from include/linux/memcontrol.h~memory-controller-add-mm-owner +8 -1

@@ -29,6 +29,7 @@ struct mm_struct;
 
 extern void mm_init_cgroup(struct mm_struct *mm, struct task_struct *p);
 extern void mm_free_cgroup(struct mm_struct *mm);
+extern void mem_cgroup_fork_init(struct task_struct *p);
 
 #define page_reset_bad_cgroup(page)	((page)->page_cgroup = 0)
 

@@ -49,7 +50,7 @@ extern void mem_cgroup_out_of_memory(str
 int task_in_mem_cgroup(struct task_struct *task, const struct mem_cgroup *mem);
 
 #define mm_match_cgroup(mm, cgroup)	\
-	((cgroup) == rcu_dereference((mm)->mem_cgroup))
+	((cgroup) == mem_cgroup_from_task((mm)->owner))
 
 extern int mem_cgroup_prepare_migration(struct page *page);
 extern void mem_cgroup_end_migration(struct page *page);

@@ -72,6 +73,8 @@ extern long mem_cgroup_calc_reclaim_acti
 extern long mem_cgroup_calc_reclaim_inactive(struct mem_cgroup *mem,
 				struct zone *zone, int priority);
 
+extern struct mem_cgroup *mem_cgroup_from_task(struct task_struct *p);
+
 #else /* CONFIG_CGROUP_MEM_RES_CTLR */
 static inline void mm_init_cgroup(struct mm_struct *mm,
 					struct task_struct *p)

@@ -82,6 +85,10 @@ static inline void mm_free_cgroup(struct
 {
 }
 
+static inline void mem_cgroup_fork_init(struct task_struct *p)
+{
+}
+
 static inline void page_reset_bad_cgroup(struct page *page)
 {
 }

include/linux/memcontrol.h renamed from include/linux/memcontrol.h~memory-controller-add-mm-owner +0 -0

 #endif /* CONFIG_CGROUP_MEM_CONT */
 
 #endif /* _LINUX_MEMCONTROL_H */

diff -puN mm/memcontrol.c~memory-controller-add-mm-owner mm/memcontrol.c

mm/memcontrol.c renamed from mm/memcontrol.c~memory-controller-add-mm-owner +1 -1

@@ -236,7 +236,7 @@ static struct mem_cgroup *mem_cgroup_fro
 				css);
 }
 
-static struct mem_cgroup *mem_cgroup_from_task(struct task_struct *p)
+struct mem_cgroup *mem_cgroup_from_task(struct task_struct *p)
 {
 	return container_of(task_subsys_state(p, mem_cgroup_subsys_id),
 				struct mem_cgroup, css);

@@ -248,12 +248,40 @@ void mm_init_cgroup(struct mm_struct *mm
 

mm/memcontrol.c renamed from mm/memcontrol.c~memory-controller-add-mm-owner +26 -6

+	if (!mm)
+		return;
+
+	/*
+	 * Initial owner at mm_init_cgroup() time is the task itself.
+	 * The thread group leader had not been setup then
+	 */
+	oldmem = mem_cgroup_from_task(mm->owner);
+	/*
+	 * Override the mm->owner after we know the thread group later
+	 */
+	mm->owner = p->group_leader;
+	mem = mem_cgroup_from_task(mm->owner);
+	css_get(&mem->css);
+	css_put(&oldmem->css);
+	mmput(mm);
 }
 
 void mm_free_cgroup(struct mm_struct *mm)
 {
-	css_put(&mm->mem_cgroup->css);
+	struct mem_cgroup *mem;
+
+	/*
+	 * TODO: Should we assign mm->owner to NULL here?
+	 */
+	mem = mem_cgroup_from_task(mm->owner);
+	css_put(&mem->css);
 }
 
 static inline int page_cgroup_locked(struct page *page)

@@ -476,6 +504,7 @@ unsigned long mem_cgroup_isolate_pages(u
 	int zid = zone_idx(z);
 	struct mem_cgroup_per_zone *mz;
 
+	BUG_ON(!mem_cont);
 	mz = mem_cgroup_zoneinfo(mem_cont, nid, zid);
 	if (active)
 		src = &mz->active_list;

@@ -573,13 +602,11 @@ retry:
 	if (!mm)
 		mm = &init_mm;
 
-	rcu_read_lock();
-	mem = rcu_dereference(mm->mem_cgroup);
+	mem = mem_cgroup_from_task(mm->owner);
 	/*
 	 * For every charge from the cgroup, increment reference count
 	 */
 	css_get(&mem->css);
-	rcu_read_unlock();
 
 	while (res_counter_charge(&mem->res, PAGE_SIZE)) {
 		if (!(gfp_mask & __GFP_WAIT))

@@ -988,7 +1015,7 @@ mem_cgroup_create(struct cgroup_subsys *
 
 	if (unlikely((cont->parent) == NULL)) {
 		mem = &init_mem_cgroup;
-		init_mm.mem_cgroup = mem;
+		init_mm.owner = &init_task;
 	} else
 		mem = kzalloc(sizeof(struct mem_cgroup), GFP_KERNEL);
 

@@ -1069,7 +1096,6 @@ static void mem_cgroup_move_task(struct 
 		goto out;
 
 	css_get(&mem->css);
-	rcu_assign_pointer(mm->mem_cgroup, mem);
 	css_put(&old_mem->css);
 
 out:

_

Quoted 94 lines · Balbir Singh

This patch removes the mem_cgroup member from mm_struct and instead adds an owner. This approach was suggested by Paul Menage. The advantage of this approach is that, once the mm->owner is known, using the subsystem id, the cgroup can be determined. It also allows several control groups that are virtually grouped by mm_struct, to exist independent of the memory controller i.e., without adding mem_cgroup's for each controller, to mm_struct.

The code initially assigns mm->owner to the task and then after the thread group leader is identified. The mm->owner is changed to the thread group leader of the task later at the end of copy_process.

Signed-off-by Balbir Singh <[email protected]>

---

 include/linux/memcontrol.h |   14 +++++++++++++-
 include/linux/mm_types.h   |    5 ++++-
 kernel/fork.c              |    4 ++++
 mm/memcontrol.c            |   42 ++++++++++++++++++++++++++++++++++--------
 4 files changed, 55 insertions(+), 10 deletions(-)

diff -puN include/linux/mm_types.h~memory-controller-add-mm-owner include/linux/mm_types.h

include/linux/mm_types.h 2008-03-20 15:11:05.000000000 +0530 renamed from include/linux/mm_types.h~memory-controller-add-mm-owner 2008-03-20 13:35:09.000000000 +0530 +4 -1

@@ -228,7 +228,10 @@ struct mm_struct {
      rwlock_t                ioctx_list_lock;
      struct kioctx           *ioctx_list;
 #ifdef CONFIG_CGROUP_MEM_RES_CTLR
-     struct mem_cgroup *mem_cgroup;
+     struct task_struct *owner;      /* The thread group leader that */
+                                     /* owns the mm_struct. This     */
+                                     /* might be useful even outside */
+                                     /* of the config option         */
 #endif
 
 #ifdef CONFIG_PROC_FS

diff -puN kernel/fork.c~memory-controller-add-mm-owner kernel/fork.c

kernel/fork.c 2008-03-24 18:49:29.000000000 +0530 renamed from kernel/fork.c~memory-controller-add-mm-owner 2008-03-20 13:35:09.000000000 +0530 +4 -0

@@ -1357,6 +1357,10 @@ static struct task_struct *copy_process(
      write_unlock_irq(&tasklist_lock);
      proc_fork_connector(p);
      cgroup_post_fork(p);
+
+     if (!(clone_flags & CLONE_VM))
+             mem_cgroup_fork_init(p);
+
      return p;
 
 bad_fork_free_pid:

diff -puN include/linux/memcontrol.h~memory-controller-add-mm-owner include/linux/memcontrol.h

include/linux/memcontrol.h 2008-03-24 18:49:52.000000000 +0530 renamed from include/linux/memcontrol.h~memory-controller-add-mm-owner 2008-03-20 13:35:09.000000000 +0530 +8 -1

@@ -29,6 +29,7 @@ struct mm_struct;
 
 extern void mm_init_cgroup(struct mm_struct *mm, struct task_struct *p);
 extern void mm_free_cgroup(struct mm_struct *mm);
+extern void mem_cgroup_fork_init(struct task_struct *p);
 
 #define page_reset_bad_cgroup(page)  ((page)->page_cgroup = 0)
 

@@ -49,7 +50,7 @@ extern void mem_cgroup_out_of_memory(str
 int task_in_mem_cgroup(struct task_struct *task, const struct mem_cgroup *mem);
 
 #define mm_match_cgroup(mm, cgroup)  \
-     ((cgroup) == rcu_dereference((mm)->mem_cgroup))
+     ((cgroup) == mem_cgroup_from_task((mm)->owner))
 
 extern int mem_cgroup_prepare_migration(struct page *page);
 extern void mem_cgroup_end_migration(struct page *page);

@@ -72,6 +73,8 @@ extern long mem_cgroup_calc_reclaim_acti
 extern long mem_cgroup_calc_reclaim_inactive(struct mem_cgroup *mem,
                              struct zone *zone, int priority);
 
+extern struct mem_cgroup *mem_cgroup_from_task(struct task_struct *p);
+
 #else /* CONFIG_CGROUP_MEM_RES_CTLR */
 static inline void mm_init_cgroup(struct mm_struct *mm,
                                      struct task_struct *p)

@@ -82,6 +85,10 @@ static inline void mm_free_cgroup(struct
 {
 }
 
+static inline void mem_cgroup_fork_init(struct task_struct *p)
+{
+}
+
 static inline void page_reset_bad_cgroup(struct page *page)
 {
 }

@@ -172,6 +179,11 @@ static inline long mem_cgroup_calc_recla
 {
      return 0;
 }

include/linux/memcontrol.h 2008-03-24 18:49:52.000000000 +0530 static inline long mem_cgroup_calc_recla · line 186

Quoted 5 lines

include/linux/memcontrol.h 2008-03-24 18:49:52.000000000 +0530 renamed from include/linux/memcontrol.h~memory-controller-add-mm-owner 2008-03-20 13:35:09.000000000 +0530 +5 -0

+
+static void mm_free_fork_cgroup(struct task_struct *p)
+{
+}
+

Where is this function used? I don't see the corresponding one with CONFIG_CGROUP_MEM_RES_CTLR enabled?

Quoted 18 lines

include/linux/memcontrol.h 2008-03-24 18:49:52.000000000 +0530 renamed from include/linux/memcontrol.h~memory-controller-add-mm-owner 2008-03-20 13:35:09.000000000 +0530 +0 -0

 #endif /* CONFIG_CGROUP_MEM_CONT */
 
 #endif /* _LINUX_MEMCONTROL_H */

diff -puN mm/memcontrol.c~memory-controller-add-mm-owner mm/memcontrol.c

mm/memcontrol.c 2008-03-24 19:04:32.000000000 +0530 renamed from mm/memcontrol.c~memory-controller-add-mm-owner 2008-03-20 13:35:09.000000000 +0530 +1 -1

@@ -236,7 +236,7 @@ static struct mem_cgroup *mem_cgroup_fro
                              css);
 }
 
-static struct mem_cgroup *mem_cgroup_from_task(struct task_struct *p)
+struct mem_cgroup *mem_cgroup_from_task(struct task_struct *p)
 {
      return container_of(task_subsys_state(p, mem_cgroup_subsys_id),
                              struct mem_cgroup, css);

@@ -248,12 +248,40 @@ void mm_init_cgroup(struct mm_struct *mm
 

mm/memcontrol.c 2008-03-24 19:04:32.000000000 +0530 void mm_init_cgroup(struct mm_struct *mm · line 257

Quoted 10 lines

mm/memcontrol.c 2008-03-24 19:04:32.000000000 +0530 renamed from mm/memcontrol.c~memory-controller-add-mm-owner 2008-03-20 13:35:09.000000000 +0530 +7 -1

      mem = mem_cgroup_from_task(p);
      css_get(&mem->css);
-     mm->mem_cgroup = mem;
+     mm->owner = p;
+}
+
+void mem_cgroup_fork_init(struct task_struct *p)
+{
+     struct mm_struct *mm = get_task_mm(p);
+     struct mem_cgroup *mem, *oldmem;

Leave an empty line here.