Skip to contentSkip to conversation

New: rmdir on cgroup can cause hang tasks

Bugme-new Andrew Morton 3 participants 6 messages Mar 4, 2011 – Mar 7, 2011 1 message not in the archive

Subsystems (2)
Memory management memcg
lore
Share & tools
lore

Andrew Morton

author maintainer
#1 lore raw
In reply to a message not in the archive

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 92 lines · On Fri, 4 Mar 2011 04:27:26 GMT [email protected] wrote:

https://bugzilla.kernel.org/show_bug.cgi?id=30432

Summary: rmdir on cgroup can cause hang tasks
Product: Process Management
Version: 2.5
Kernel Version: 2.6.37
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: Other
AssignedTo: [email protected]
ReportedBy: [email protected]
Regression: No

I just got following hang when removing an empty cgroup. I had still a shell in the cgroup that got emptied and removed. The shell as well as the release_agent and the program managing the cgroup hangs.

The directory structure looks like:
/sys/fs/cgroup/memory/usr_1000/psn_3234

ls on /sys/fs/cgroup/memory but ls on /sys/fs/cgroup/memory/usr_1000 hangs.

[ 5065.280666] SysRq : Changing Loglevel
[ 5065.282574] Loglevel set to 5
[ 5066.139879] SysRq : Show Blocked State
[ 5066.141848]   task                        PC stack   pid father
[ 5066.141925] zsh           D ffff880071520398     0  8719   3589 0x00000084
[ 5066.141937]  ffff880002059bd8 0000000000000086 ffff880002059bb8
ffffffff00000000
[ 5066.143971]  00000000000139c0 ffff880071520000 ffff880071520398
ffff880002059fd8
[ 5066.146049]  ffff8800715203a0 00000000000139c0 ffff880002058010
00000000000139c0
[ 5066.148183] Call Trace:
[ 5066.149853]  [<ffffffff8158ec97>] __mutex_lock_slowpath+0xf7/0x180
[ 5066.149853]  [<ffffffff812d74a6>] ? vsnprintf+0x416/0x5a0
[ 5066.149853]  [<ffffffff8158eb7b>] mutex_lock+0x2b/0x50
[ 5066.149853]  [<ffffffff81168252>] do_lookup+0x102/0x180
[ 5066.149853]  [<ffffffff81168dfd>] link_path_walk+0x4dd/0x9e0
[ 5066.149853]  [<ffffffff81169417>] path_walk+0x67/0xe0
[ 5066.149853]  [<ffffffff811695eb>] do_path_lookup+0x5b/0xa0
[ 5066.149853]  [<ffffffff8116a2f7>] user_path_at+0x57/0xa0
[ 5066.149853]  [<ffffffff815940e0>] ? do_page_fault+0x1f0/0x4f0
[ 5066.149853]  [<ffffffff81075e6c>] ? kill_pid_info+0x2c/0x60
[ 5066.149853]  [<ffffffff811604fc>] vfs_fstatat+0x3c/0x80
[ 5066.149853]  [<ffffffff8116061b>] vfs_stat+0x1b/0x20
[ 5066.149853]  [<ffffffff81160644>] sys_newstat+0x24/0x50
[ 5066.149853]  [<ffffffff810bf6ff>] ? audit_syscall_entry+0x1df/0x280
[ 5066.149853]  [<ffffffff8100c042>] system_call_fastpath+0x16/0x1b
[ 5066.149853] ulatencyd     D ffff88007a0bc7d8     0  9004   4809 0x00000084
[ 5066.149853]  ffff880070b55cd8 0000000000000082 0000000000000082
ffff88002c9d16c0
[ 5066.149853]  00000000000139c0 ffff88007a0bc440 ffff88007a0bc7d8
ffff880070b55fd8
[ 5066.149853]  ffff88007a0bc7e0 00000000000139c0 ffff880070b54010
00000000000139c0
[ 5066.149853] Call Trace:
[ 5066.149853]  [<ffffffff8158ec97>] __mutex_lock_slowpath+0xf7/0x180
[ 5066.149853]  [<ffffffff81166124>] ? exec_permission+0x44/0x90
[ 5066.149853]  [<ffffffff8158eb7b>] mutex_lock+0x2b/0x50
[ 5066.149853]  [<ffffffff81168418>] do_last+0x148/0x650
[ 5066.149853]  [<ffffffff8116a6d5>] do_filp_open+0x205/0x5f0
[ 5066.149853]  [<ffffffff81167281>] ? path_put+0x31/0x40
[ 5066.149853]  [<ffffffff8117593a>] ? alloc_fd+0x10a/0x150
[ 5066.149853]  [<ffffffff81159bb9>] do_sys_open+0x69/0x110
[ 5066.149853]  [<ffffffff81159ca0>] sys_open+0x20/0x30
[ 5066.149853]  [<ffffffff8100c042>] system_call_fastpath+0x16/0x1b
[ 5066.149853] lua           D ffff88002c91b118     0  9487      1 0x00000080
[ 5066.149853]  ffff880078f6db08 0000000000000086 ffff88002c91b118
ffff880000000000
[ 5066.149853]  00000000000139c0 ffff88002c91ad80 ffff88002c91b118
ffff880078f6dfd8
[ 5066.149853]  ffff88002c91b120 00000000000139c0 ffff880078f6c010
00000000000139c0
[ 5066.149853] Call Trace:
[ 5066.149853]  [<ffffffff8158e4d5>] schedule_timeout+0x215/0x2f0
[ 5066.149853]  [<ffffffff8104e4fd>] ? task_rq_lock+0x5d/0xa0
[ 5066.149853]  [<ffffffff81059c93>] ? try_to_wake_up+0xc3/0x410
[ 5066.149853]  [<ffffffff8158e0cb>] wait_for_common+0xdb/0x180
[ 5066.149853]  [<ffffffff81059fe0>] ? default_wake_function+0x0/0x20
[ 5066.244366]  [<ffffffff8158e24d>] wait_for_completion+0x1d/0x20
[ 5066.244366]  [<ffffffff810d44f5>] synchronize_sched+0x55/0x60
[ 5066.244366]  [<ffffffff81080b00>] ? wakeme_after_rcu+0x0/0x20
[ 5066.244366]  [<ffffffff811526a3>] mem_cgroup_start_move+0x93/0xa0
[ 5066.244366]  [<ffffffff8115739b>] mem_cgroup_force_empty+0xdb/0x640
[ 5066.244366]  [<ffffffff81157914>] mem_cgroup_pre_destroy+0x14/0x20
Quoted 8 lines
[ 5066.244366]  [<ffffffff810ae681>] cgroup_rmdir+0xc1/0x560
[ 5066.244366]  [<ffffffff81083d70>] ? autoremove_wake_function+0x0/0x40
[ 5066.244366]  [<ffffffff81167cc4>] vfs_rmdir+0xb4/0x110
[ 5066.244366]  [<ffffffff81169d13>] do_rmdir+0x133/0x140
[ 5066.244366]  [<ffffffff810d3c85>] ? call_rcu_sched+0x15/0x20
[ 5066.244366]  [<ffffffff810bf6ff>] ? audit_syscall_entry+0x1df/0x280
[ 5066.244366]  [<ffffffff81169d76>] sys_rmdir+0x16/0x20
[ 5066.244366]  [<ffffffff8100c042>] system_call_fastpath+0x16/0x1b

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#2 lore raw
Quoted 12 lines · On Fri, 4 Mar 2011 00:03:55 -0800 Andrew Morton <[email protected]>…
Quoted 12 lines
[ 5066.149853] Call Trace:
[ 5066.149853]  [<ffffffff8158e4d5>] schedule_timeout+0x215/0x2f0
[ 5066.149853]  [<ffffffff8104e4fd>] ? task_rq_lock+0x5d/0xa0
[ 5066.149853]  [<ffffffff81059c93>] ? try_to_wake_up+0xc3/0x410
[ 5066.149853]  [<ffffffff8158e0cb>] wait_for_common+0xdb/0x180
[ 5066.149853]  [<ffffffff81059fe0>] ? default_wake_function+0x0/0x20
[ 5066.244366]  [<ffffffff8158e24d>] wait_for_completion+0x1d/0x20
[ 5066.244366]  [<ffffffff810d44f5>] synchronize_sched+0x55/0x60
[ 5066.244366]  [<ffffffff81080b00>] ? wakeme_after_rcu+0x0/0x20
[ 5066.244366]  [<ffffffff811526a3>] mem_cgroup_start_move+0x93/0xa0
[ 5066.244366]  [<ffffffff8115739b>] mem_cgroup_force_empty+0xdb/0x640
[ 5066.244366]  [<ffffffff81157914>] mem_cgroup_pre_destroy+0x14/0x20
Quoted 9 lines
Quoted 8 lines
[ 5066.244366]  [<ffffffff810ae681>] cgroup_rmdir+0xc1/0x560
[ 5066.244366]  [<ffffffff81083d70>] ? autoremove_wake_function+0x0/0x40
[ 5066.244366]  [<ffffffff81167cc4>] vfs_rmdir+0xb4/0x110
[ 5066.244366]  [<ffffffff81169d13>] do_rmdir+0x133/0x140
[ 5066.244366]  [<ffffffff810d3c85>] ? call_rcu_sched+0x15/0x20
[ 5066.244366]  [<ffffffff810bf6ff>] ? audit_syscall_entry+0x1df/0x280
[ 5066.244366]  [<ffffffff81169d76>] sys_rmdir+0x16/0x20
[ 5066.244366]  [<ffffffff8100c042>] system_call_fastpath+0x16/0x1b

This seems....
==
static void mem_cgroup_start_move(struct mem_cgroup *mem) {
.....

	put_online_cpus();

        synchronize_rcu();   <---------(*)
}

==

Waiting on above synchronize_rcu().

Hmm...
-Kame

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#3 lore raw

On Fri, 4 Mar 2011 17:28:15 +0900
KAMEZAWA Hiroyuki <[email protected]> wrote:
This seems....

Quoted 10 lines

==
static void mem_cgroup_start_move(struct mem_cgroup *mem) {
.....

	put_online_cpus();

        synchronize_rcu();   <---------(*)
}

==

But this may scan LRU of memcg forever and SysRq+T just shows above stack.

I'll check a tree before THP and force_empty again -Kame

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#6 lore raw
In reply to Andrew Morton

Hi, thank you for your report.

I have some questions.

Quoted 28 lines · On Fri, 4 Mar 2011 00:03:55 -0800 Andrew Morton <[email protected]>…

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 22 lines · On Fri, 4 Mar 2011 04:27:26 GMT [email protected] wrote:

https://bugzilla.kernel.org/show_bug.cgi?id=30432

Summary: rmdir on cgroup can cause hang tasks
Product: Process Management
Version: 2.5
Kernel Version: 2.6.37
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: Other
AssignedTo: [email protected]
ReportedBy: [email protected]
Regression: No

I just got following hang when removing an empty cgroup. I had still a shell in the cgroup that got emptied and removed. The shell as well as the release_agent and the program managing the cgroup hangs.

You tried to remove a cgroup directory via release_agent(i.e. you enabled "notify_on_release", and make the release_agent remove the directory)?

And can you show your /proc/cgroups ?

Thanks,
Daisuke Nishimura.

Quoted 79 lines
Quoted 70 lines

The directory structure looks like:
/sys/fs/cgroup/memory/usr_1000/psn_3234

ls on /sys/fs/cgroup/memory but ls on /sys/fs/cgroup/memory/usr_1000 hangs.

[ 5065.280666] SysRq : Changing Loglevel
[ 5065.282574] Loglevel set to 5
[ 5066.139879] SysRq : Show Blocked State
[ 5066.141848]   task                        PC stack   pid father
[ 5066.141925] zsh           D ffff880071520398     0  8719   3589 0x00000084
[ 5066.141937]  ffff880002059bd8 0000000000000086 ffff880002059bb8
ffffffff00000000
[ 5066.143971]  00000000000139c0 ffff880071520000 ffff880071520398
ffff880002059fd8
[ 5066.146049]  ffff8800715203a0 00000000000139c0 ffff880002058010
00000000000139c0
[ 5066.148183] Call Trace:
[ 5066.149853]  [<ffffffff8158ec97>] __mutex_lock_slowpath+0xf7/0x180
[ 5066.149853]  [<ffffffff812d74a6>] ? vsnprintf+0x416/0x5a0
[ 5066.149853]  [<ffffffff8158eb7b>] mutex_lock+0x2b/0x50
[ 5066.149853]  [<ffffffff81168252>] do_lookup+0x102/0x180
[ 5066.149853]  [<ffffffff81168dfd>] link_path_walk+0x4dd/0x9e0
[ 5066.149853]  [<ffffffff81169417>] path_walk+0x67/0xe0
[ 5066.149853]  [<ffffffff811695eb>] do_path_lookup+0x5b/0xa0
[ 5066.149853]  [<ffffffff8116a2f7>] user_path_at+0x57/0xa0
[ 5066.149853]  [<ffffffff815940e0>] ? do_page_fault+0x1f0/0x4f0
[ 5066.149853]  [<ffffffff81075e6c>] ? kill_pid_info+0x2c/0x60
[ 5066.149853]  [<ffffffff811604fc>] vfs_fstatat+0x3c/0x80
[ 5066.149853]  [<ffffffff8116061b>] vfs_stat+0x1b/0x20
[ 5066.149853]  [<ffffffff81160644>] sys_newstat+0x24/0x50
[ 5066.149853]  [<ffffffff810bf6ff>] ? audit_syscall_entry+0x1df/0x280
[ 5066.149853]  [<ffffffff8100c042>] system_call_fastpath+0x16/0x1b
[ 5066.149853] ulatencyd     D ffff88007a0bc7d8     0  9004   4809 0x00000084
[ 5066.149853]  ffff880070b55cd8 0000000000000082 0000000000000082
ffff88002c9d16c0
[ 5066.149853]  00000000000139c0 ffff88007a0bc440 ffff88007a0bc7d8
ffff880070b55fd8
[ 5066.149853]  ffff88007a0bc7e0 00000000000139c0 ffff880070b54010
00000000000139c0
[ 5066.149853] Call Trace:
[ 5066.149853]  [<ffffffff8158ec97>] __mutex_lock_slowpath+0xf7/0x180
[ 5066.149853]  [<ffffffff81166124>] ? exec_permission+0x44/0x90
[ 5066.149853]  [<ffffffff8158eb7b>] mutex_lock+0x2b/0x50
[ 5066.149853]  [<ffffffff81168418>] do_last+0x148/0x650
[ 5066.149853]  [<ffffffff8116a6d5>] do_filp_open+0x205/0x5f0
[ 5066.149853]  [<ffffffff81167281>] ? path_put+0x31/0x40
[ 5066.149853]  [<ffffffff8117593a>] ? alloc_fd+0x10a/0x150
[ 5066.149853]  [<ffffffff81159bb9>] do_sys_open+0x69/0x110
[ 5066.149853]  [<ffffffff81159ca0>] sys_open+0x20/0x30
[ 5066.149853]  [<ffffffff8100c042>] system_call_fastpath+0x16/0x1b
[ 5066.149853] lua           D ffff88002c91b118     0  9487      1 0x00000080
[ 5066.149853]  ffff880078f6db08 0000000000000086 ffff88002c91b118
ffff880000000000
[ 5066.149853]  00000000000139c0 ffff88002c91ad80 ffff88002c91b118
ffff880078f6dfd8
[ 5066.149853]  ffff88002c91b120 00000000000139c0 ffff880078f6c010
00000000000139c0
[ 5066.149853] Call Trace:
[ 5066.149853]  [<ffffffff8158e4d5>] schedule_timeout+0x215/0x2f0
[ 5066.149853]  [<ffffffff8104e4fd>] ? task_rq_lock+0x5d/0xa0
[ 5066.149853]  [<ffffffff81059c93>] ? try_to_wake_up+0xc3/0x410
[ 5066.149853]  [<ffffffff8158e0cb>] wait_for_common+0xdb/0x180
[ 5066.149853]  [<ffffffff81059fe0>] ? default_wake_function+0x0/0x20
[ 5066.244366]  [<ffffffff8158e24d>] wait_for_completion+0x1d/0x20
[ 5066.244366]  [<ffffffff810d44f5>] synchronize_sched+0x55/0x60
[ 5066.244366]  [<ffffffff81080b00>] ? wakeme_after_rcu+0x0/0x20
[ 5066.244366]  [<ffffffff811526a3>] mem_cgroup_start_move+0x93/0xa0
[ 5066.244366]  [<ffffffff8115739b>] mem_cgroup_force_empty+0xdb/0x640
[ 5066.244366]  [<ffffffff81157914>] mem_cgroup_pre_destroy+0x14/0x20
Quoted 8 lines
[ 5066.244366]  [<ffffffff810ae681>] cgroup_rmdir+0xc1/0x560
[ 5066.244366]  [<ffffffff81083d70>] ? autoremove_wake_function+0x0/0x40
[ 5066.244366]  [<ffffffff81167cc4>] vfs_rmdir+0xb4/0x110
[ 5066.244366]  [<ffffffff81169d13>] do_rmdir+0x133/0x140
[ 5066.244366]  [<ffffffff810d3c85>] ? call_rcu_sched+0x15/0x20
[ 5066.244366]  [<ffffffff810bf6ff>] ? audit_syscall_entry+0x1df/0x280
[ 5066.244366]  [<ffffffff81169d76>] sys_rmdir+0x16/0x20
[ 5066.244366]  [<ffffffff8100c042>] system_call_fastpath+0x16/0x1b
Quoted 6 lines

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#4 lore raw
In reply to KAMEZAWA Hiroyuki
Quoted 14 lines · On Fri, 4 Mar 2011 18:01:57 +0900 KAMEZAWA Hiroyuki…

On Fri, 4 Mar 2011 17:28:15 +0900
KAMEZAWA Hiroyuki <[email protected]> wrote:
This seems....

Quoted 10 lines

==
static void mem_cgroup_start_move(struct mem_cgroup *mem) {
.....

	put_online_cpus();

        synchronize_rcu();   <---------(*)
}

==

Quoted 4 lines

But this may scan LRU of memcg forever and SysRq+T just shows above stack.

I'll check a tree before THP and force_empty again

Hmm, one more conern is what kind of file system is used ?

Can I see
- /prco/mounts
and your .config ?

If you use FUSE, could you try this ?

I'll prepare one for mmotm.

==

fs/fuse/dev.c::fuse_try_move_page() does

(1) remove a page by ->steal()
(2) re-add the page to page cache
(3) link the page to LRU if it was not on LRU at (1)

This implies the page is _on_ LRU when it's added to radix-tree. So, the page is added to memory cgroup while it's on LRU. because LRU is lazy and no one flushs it.

This is the same behavior as SwapCache and needs special care as
- remove page from LRU before overwrite pc->mem_cgroup.
- add page to LRU after overwrite pc->mem_cgroup.

So, reusing it with renaming.

Note: a page on pagevec(LRU).
If a page is not PageLRU(page) but on pagevec(LRU), it may be added to LRU while we overwrite page->mapping. But in that case, PCG_USED bit of the page_cgroup is not set and the page_cgroup will not be added to wrong memcg's LRU. So, this patch's logic will work fine.
(It has been tested with SwapCache.)

Signed-off-by KAMEZAWA Hiroyuki <[email protected]>
---
 mm/memcontrol.c |   45 +++++++++++++++++++++++++++------------------
 1 file changed, 27 insertions(+), 18 deletions(-)
mm/memcontrol.c +27 -18
Index: linux-2.6.37/mm/memcontrol.c
===================================================================
@@ -876,13 +876,12 @@ void mem_cgroup_add_lru_list(struct page
 }
 
 /*
- * At handling SwapCache, pc->mem_cgroup may be changed while it's linked to
- * lru because the page may.be reused after it's fully uncharged (because of
- * SwapCache behavior).To handle that, unlink page_cgroup from LRU when charge
- * it again. This function is only used to charge SwapCache. It's done under
- * lock_page and expected that zone->lru_lock is never held.
+ * At handling SwapCache and other FUSE stuff, pc->mem_cgroup may be changed
+ * while it's linked to lru because the page may be reused after it's fully
+ * uncharged. To handle that, unlink page_cgroup from LRU when charge it again.
+ * It's done under lock_page and expected that zone->lru_lock isnever held.
  */
-static void mem_cgroup_lru_del_before_commit_swapcache(struct page *page)
+static void mem_cgroup_lru_del_before_commit(struct page *page)
 {
 	unsigned long flags;
 	struct zone *zone = page_zone(page);

@@ -898,7 +897,7 @@ static void mem_cgroup_lru_del_before_co
 	spin_unlock_irqrestore(&zone->lru_lock, flags);
 }
 
-static void mem_cgroup_lru_add_after_commit_swapcache(struct page *page)
+static void mem_cgroup_lru_add_after_commit(struct page *page)
 {
 	unsigned long flags;
 	struct zone *zone = page_zone(page);

@@ -2299,7 +2298,7 @@ int mem_cgroup_newpage_charge(struct pag
 }
 
 static void
-__mem_cgroup_commit_charge_swapin(struct page *page, struct mem_cgroup *ptr,
+__mem_cgroup_commit_charge_lrucare(struct page *page, struct mem_cgroup *ptr,
 					enum charge_type ctype);
 
 int mem_cgroup_cache_charge(struct page *page, struct mm_struct *mm,

@@ -2339,18 +2338,28 @@ int mem_cgroup_cache_charge(struct page 
 	if (unlikely(!mm))
 		mm = &init_mm;
 
-	if (page_is_file_cache(page))
-		return mem_cgroup_charge_common(page, mm, gfp_mask,
+	/*
+	 * FUSE has a logic to reuse existing page-cache before free().
+	 * It means the 'page' may be on some LRU. SwapCache has the
+	 * same kind of handling.
+	 */
+	if (page_is_file_cache(page) && !PageLRU(page)) {
+		ret = mem_cgroup_charge_common(page, mm, gfp_mask,
 				MEM_CGROUP_CHARGE_TYPE_CACHE);
+	} else if (page_is_file_cache(page)) {
+		struct mem_cgroup *mem = NULL;
 
-	/* shmem */
-	if (PageSwapCache(page)) {
+		ret = __mem_cgroup_try_charge(mm, gfp_mask, &mem, true);
+		if (!ret)
+			__mem_cgroup_commit_charge_lrucare(page, mem,
+				MEM_CGROUP_CHARGE_TYPE_CACHE);
+	} else if (PageSwapCache(page)) {
 		struct mem_cgroup *mem = NULL;
 
 		ret = mem_cgroup_try_charge_swapin(mm, page, gfp_mask, &mem);
 		if (!ret)
-			__mem_cgroup_commit_charge_swapin(page, mem,
-					MEM_CGROUP_CHARGE_TYPE_SHMEM);
+			__mem_cgroup_commit_charge_lrucare(page, mem,
+				MEM_CGROUP_CHARGE_TYPE_SHMEM);
 	} else
 		ret = mem_cgroup_charge_common(page, mm, gfp_mask,
 					MEM_CGROUP_CHARGE_TYPE_SHMEM);

@@ -2398,7 +2407,7 @@ charge_cur_mm:
 }
 
 static void
-__mem_cgroup_commit_charge_swapin(struct page *page, struct mem_cgroup *ptr,
+__mem_cgroup_commit_charge_lrucare(struct page *page, struct mem_cgroup *ptr,
 					enum charge_type ctype)
 {
 	struct page_cgroup *pc;

@@ -2409,9 +2418,9 @@ __mem_cgroup_commit_charge_swapin(struct
 		return;
 	cgroup_exclude_rmdir(&ptr->css);
 	pc = lookup_page_cgroup(page);
-	mem_cgroup_lru_del_before_commit_swapcache(page);
+	mem_cgroup_lru_del_before_commit(page);
 	__mem_cgroup_commit_charge(ptr, pc, ctype);
-	mem_cgroup_lru_add_after_commit_swapcache(page);
+	mem_cgroup_lru_add_after_commit(page);
 	/*
 	 * Now swap is on-memory. This means this page may be
 	 * counted both as mem and swap....double count.

@@ -2449,7 +2458,7 @@ __mem_cgroup_commit_charge_swapin(struct
 
 void mem_cgroup_commit_charge_swapin(struct page *page, struct mem_cgroup *ptr)
 {
-	__mem_cgroup_commit_charge_swapin(page, ptr,
+	__mem_cgroup_commit_charge_lrucare(page, ptr,
 					MEM_CGROUP_CHARGE_TYPE_MAPPED);
 }

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#5 lore raw
Quoted 24 lines · On Mon, 7 Mar 2011 13:58:03 +0900 KAMEZAWA Hiroyuki…
Quoted 14 lines · On Fri, 4 Mar 2011 18:01:57 +0900 KAMEZAWA Hiroyuki…

On Fri, 4 Mar 2011 17:28:15 +0900
KAMEZAWA Hiroyuki <[email protected]> wrote:
This seems....

Quoted 10 lines

==
static void mem_cgroup_start_move(struct mem_cgroup *mem) {
.....

	put_online_cpus();

        synchronize_rcu();   <---------(*)
}

==

Quoted 4 lines

But this may scan LRU of memcg forever and SysRq+T just shows above stack.

I'll check a tree before THP and force_empty again

Hmm, one more conern is what kind of file system is used ?

Quoted 8 lines

Can I see
- /prco/mounts
and your .config ?

If you use FUSE, could you try this ?

I'll prepare one for mmotm.

Sorry, this version may contain hung-up bug...
I'll start from fix for mmotm and backport it.

Thanks,
-Kame

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>