From: Kamezawa Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> To: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org> Cc: azurIt <azurit-Rm0zKEqwvD4@public.gmane.org>, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, cgroups mailinglist <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org> Subject: Re: [PATCH for 3.2.34] memcg: do not trigger OOM from add_to_page_cache_locked Date: Fri, 08 Feb 2013 10:40:13 +0900 [thread overview] Message-ID: <5114577D.70608@jp.fujitsu.com> (raw) In-Reply-To: <51138999.3090006-+CUm20s59erQFUHtdCDX3A@public.gmane.org> (2013/02/07 20:01), Kamezawa Hiroyuki wrote: > (2013/02/06 23:01), Michal Hocko wrote: >> On Wed 06-02-13 02:17:21, azurIt wrote: >>>> 5-memcg-fix-1.patch is not complete. It doesn't contain the folloup I >>>> mentioned in a follow up email. Here is the full patch: >>> >>> >>> Here is the log where OOM, again, killed MySQL server [search for "(mysqld)"]: >>> http://www.watchdog.sk/lkml/oom_mysqld6 >> >> [...] >> WARNING: at mm/memcontrol.c:2409 T.1149+0x2d9/0x610() >> Hardware name: S5000VSA >> gfp_mask:4304 nr_pages:1 oom:0 ret:2 >> Pid: 3545, comm: apache2 Tainted: G W 3.2.37-grsec #1 >> Call Trace: >> [<ffffffff8105502a>] warn_slowpath_common+0x7a/0xb0 >> [<ffffffff81055116>] warn_slowpath_fmt+0x46/0x50 >> [<ffffffff81108163>] ? mem_cgroup_margin+0x73/0xa0 >> [<ffffffff8110b6f9>] T.1149+0x2d9/0x610 >> [<ffffffff812af298>] ? blk_finish_plug+0x18/0x50 >> [<ffffffff8110c6b4>] mem_cgroup_cache_charge+0xc4/0xf0 >> [<ffffffff810ca6bf>] add_to_page_cache_locked+0x4f/0x140 >> [<ffffffff810ca7d2>] add_to_page_cache_lru+0x22/0x50 >> [<ffffffff810cad32>] filemap_fault+0x252/0x4f0 >> [<ffffffff810eab18>] __do_fault+0x78/0x5a0 >> [<ffffffff810edcb4>] handle_pte_fault+0x84/0x940 >> [<ffffffff810e2460>] ? vma_prio_tree_insert+0x30/0x50 >> [<ffffffff810f2508>] ? vma_link+0x88/0xe0 >> [<ffffffff810ee6a8>] handle_mm_fault+0x138/0x260 >> [<ffffffff8102709d>] do_page_fault+0x13d/0x460 >> [<ffffffff810f46fc>] ? do_mmap_pgoff+0x3dc/0x430 >> [<ffffffff815b61ff>] page_fault+0x1f/0x30 >> ---[ end trace 8817670349022007 ]--- >> apache2 invoked oom-killer: gfp_mask=0x0, order=0, oom_adj=0, oom_score_adj=0 >> apache2 cpuset=uid mems_allowed=0 >> Pid: 3545, comm: apache2 Tainted: G W 3.2.37-grsec #1 >> Call Trace: >> [<ffffffff810ccd2e>] dump_header+0x7e/0x1e0 >> [<ffffffff810ccc2f>] ? find_lock_task_mm+0x2f/0x70 >> [<ffffffff810cd1f5>] oom_kill_process+0x85/0x2a0 >> [<ffffffff810cd8a5>] out_of_memory+0xe5/0x200 >> [<ffffffff810cda7d>] pagefault_out_of_memory+0xbd/0x110 >> [<ffffffff81026e76>] mm_fault_error+0xb6/0x1a0 >> [<ffffffff8102734e>] do_page_fault+0x3ee/0x460 >> [<ffffffff810f46fc>] ? do_mmap_pgoff+0x3dc/0x430 >> [<ffffffff815b61ff>] page_fault+0x1f/0x30 >> >> The first trace comes from the debugging WARN and it clearly points to >> a file fault path. __do_fault pre-charges a page in case we need to >> do CoW (copy-on-write) for the returned page. This one falls back to >> memcg OOM and never returns ENOMEM as I have mentioned earlier. >> However, the fs fault handler (filemap_fault here) can fallback to >> page_cache_read if the readahead (do_sync_mmap_readahead) fails >> to get page to the page cache. And we can see this happening in >> the first trace. page_cache_read then calls add_to_page_cache_lru >> and eventually gets to add_to_page_cache_locked which calls >> mem_cgroup_cache_charge_no_oom so we will get ENOMEM if oom should >> happen. This ENOMEM gets to the fault handler and kaboom. >> > > Hmm. do we need to increase the "limit" virtually at memcg oom until > the oom-killed process dies ? Here is my naive idea... == From 1a46318cf89e7df94bd4844f29105b61dacf335b Mon Sep 17 00:00:00 2001 From: KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> Date: Fri, 8 Feb 2013 10:43:52 +0900 Subject: [PATCH] [Don't Apply][PATCH] memcg relax resource at OOM situation. When an OOM happens, a task is killed and resources will be freed. A problem here is that a task, which is oom-killed, may wait for some other resource in which memory resource is required. Some thread waits for free memory may holds some mutex and oom-killed process wait for the mutex. To avoid this, relaxing charged memory by giving virtual resource can be a help. The system can get back it at uncharge(). This is a sample native implementation. Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> --- mm/memcontrol.c | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 73 insertions(+), 6 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 25ac5f4..4dea49a 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -301,6 +301,9 @@ struct mem_cgroup { /* set when res.limit == memsw.limit */ bool memsw_is_minimum; + /* extra resource at emergency situation */ + unsigned long loan; + spinlock_t loan_lock; /* protect arrays of thresholds */ struct mutex thresholds_lock; @@ -2034,6 +2037,61 @@ static int mem_cgroup_soft_reclaim(struct mem_cgroup *root_memcg, mem_cgroup_iter_break(root_memcg, victim); return total; } +/* + * When a memcg is in OOM situation, this lack of resource may cause deadlock + * because of complicated lock dependency(i_mutex...). To avoid that, we + * need extra resource or avoid charging. + * + * A memcg can request resource in an emergency state. We call it as loan. + * A memcg will return a loan when it does uncharge resource. We disallow + * double-loan and moving task to other groups until the loan is fully + * returned. + * + * Note: the problem here is that we cannot know what amount resouce should + * be necessary to exiting an emergency state..... + */ +#define LOAN_MAX (2 * 1024 * 1024) + +static void mem_cgroup_make_loan(struct mem_cgroup *memcg) +{ + u64 usage; + unsigned long amount; + + amount = LOAN_MAX; + + usage = res_counter_read_u64(&memcg->res, RES_USAGE); + if (amount > usage /2 ) + amount = usage / 2; + spin_lock(&memcg->loan_lock); + if (memcg->loan) { + spin_unlock(&memcg->loan_lock); + return; + } + memcg->loan = amount; + res_counter_uncharge(&memcg->res, amount); + if (do_swap_account) + res_counter_uncharge(&memcg->memsw, amount); + spin_unlock(&memcg->loan_lock); +} + +/* return amount of free resource which can be uncharged */ +static unsigned long +mem_cgroup_may_return_loan(struct mem_cgroup *memcg, unsigned long val) +{ + unsigned long tmp; + /* we don't care small race here */ + if (unlikely(!memcg->loan)) + return val; + spin_lock(&memcg->loan_lock); + if (memcg->loan) { + tmp = min(memcg->loan, val); + memcg->loan -= tmp; + val -= tmp; + } + spin_unlock(&memcg->loan_lock); + return val; +} + /* * Check OOM-Killer is already running under our hierarchy. @@ -2182,6 +2240,7 @@ static bool mem_cgroup_handle_oom(struct mem_cgroup *memcg, gfp_t mask, if (need_to_kill) { finish_wait(&memcg_oom_waitq, &owait.wait); mem_cgroup_out_of_memory(memcg, mask, order); + mem_cgroup_make_loan(memcg); } else { schedule(); finish_wait(&memcg_oom_waitq, &owait.wait); @@ -2748,6 +2807,8 @@ static void __mem_cgroup_cancel_charge(struct mem_cgroup *memcg, if (!mem_cgroup_is_root(memcg)) { unsigned long bytes = nr_pages * PAGE_SIZE; + bytes = mem_cgroup_may_return_loan(memcg, bytes); + res_counter_uncharge(&memcg->res, bytes); if (do_swap_account) res_counter_uncharge(&memcg->memsw, bytes); @@ -3989,6 +4050,7 @@ static void mem_cgroup_do_uncharge(struct mem_cgroup *memcg, { struct memcg_batch_info *batch = NULL; bool uncharge_memsw = true; + unsigned long val; /* If swapout, usage of swap doesn't decrease */ if (!do_swap_account || ctype == MEM_CGROUP_CHARGE_TYPE_SWAPOUT) @@ -4029,9 +4091,11 @@ static void mem_cgroup_do_uncharge(struct mem_cgroup *memcg, batch->memsw_nr_pages++; return; direct_uncharge: - res_counter_uncharge(&memcg->res, nr_pages * PAGE_SIZE); + val = nr_pages * PAGE_SIZE; + val = mem_cgroup_may_return_loan(memcg, val); + res_counter_uncharge(&memcg->res, val); if (uncharge_memsw) - res_counter_uncharge(&memcg->memsw, nr_pages * PAGE_SIZE); + res_counter_uncharge(&memcg->memsw, val); if (unlikely(batch->memcg != memcg)) memcg_oom_recover(memcg); } @@ -4182,6 +4246,7 @@ void mem_cgroup_uncharge_start(void) void mem_cgroup_uncharge_end(void) { struct memcg_batch_info *batch = ¤t->memcg_batch; + unsigned long val; if (!batch->do_batch) return; @@ -4192,16 +4257,16 @@ void mem_cgroup_uncharge_end(void) if (!batch->memcg) return; + val = batch->nr_pages * PAGE_SIZE; + val = mem_cgroup_may_return_loan(batch->memcg, val); /* * This "batch->memcg" is valid without any css_get/put etc... * bacause we hide charges behind us. */ if (batch->nr_pages) - res_counter_uncharge(&batch->memcg->res, - batch->nr_pages * PAGE_SIZE); + res_counter_uncharge(&batch->memcg->res, val); if (batch->memsw_nr_pages) - res_counter_uncharge(&batch->memcg->memsw, - batch->memsw_nr_pages * PAGE_SIZE); + res_counter_uncharge(&batch->memcg->memsw, val); memcg_oom_recover(batch->memcg); /* forget this pointer (for sanity check) */ batch->memcg = NULL; @@ -6291,6 +6356,8 @@ mem_cgroup_css_alloc(struct cgroup *cont) memcg->move_charge_at_immigrate = 0; mutex_init(&memcg->thresholds_lock); spin_lock_init(&memcg->move_lock); + memcg->loan = 0; + spin_lock_init(&memcg->loan_lock); return &memcg->css; -- 1.7.10.2
WARNING: multiple messages have this Message-ID (diff)
From: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> To: Michal Hocko <mhocko@suse.cz> Cc: azurIt <azurit@pobox.sk>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, cgroups mailinglist <cgroups@vger.kernel.org>, Johannes Weiner <hannes@cmpxchg.org> Subject: Re: [PATCH for 3.2.34] memcg: do not trigger OOM from add_to_page_cache_locked Date: Fri, 08 Feb 2013 10:40:13 +0900 [thread overview] Message-ID: <5114577D.70608@jp.fujitsu.com> (raw) In-Reply-To: <51138999.3090006@jp.fujitsu.com> (2013/02/07 20:01), Kamezawa Hiroyuki wrote: > (2013/02/06 23:01), Michal Hocko wrote: >> On Wed 06-02-13 02:17:21, azurIt wrote: >>>> 5-memcg-fix-1.patch is not complete. It doesn't contain the folloup I >>>> mentioned in a follow up email. Here is the full patch: >>> >>> >>> Here is the log where OOM, again, killed MySQL server [search for "(mysqld)"]: >>> http://www.watchdog.sk/lkml/oom_mysqld6 >> >> [...] >> WARNING: at mm/memcontrol.c:2409 T.1149+0x2d9/0x610() >> Hardware name: S5000VSA >> gfp_mask:4304 nr_pages:1 oom:0 ret:2 >> Pid: 3545, comm: apache2 Tainted: G W 3.2.37-grsec #1 >> Call Trace: >> [<ffffffff8105502a>] warn_slowpath_common+0x7a/0xb0 >> [<ffffffff81055116>] warn_slowpath_fmt+0x46/0x50 >> [<ffffffff81108163>] ? mem_cgroup_margin+0x73/0xa0 >> [<ffffffff8110b6f9>] T.1149+0x2d9/0x610 >> [<ffffffff812af298>] ? blk_finish_plug+0x18/0x50 >> [<ffffffff8110c6b4>] mem_cgroup_cache_charge+0xc4/0xf0 >> [<ffffffff810ca6bf>] add_to_page_cache_locked+0x4f/0x140 >> [<ffffffff810ca7d2>] add_to_page_cache_lru+0x22/0x50 >> [<ffffffff810cad32>] filemap_fault+0x252/0x4f0 >> [<ffffffff810eab18>] __do_fault+0x78/0x5a0 >> [<ffffffff810edcb4>] handle_pte_fault+0x84/0x940 >> [<ffffffff810e2460>] ? vma_prio_tree_insert+0x30/0x50 >> [<ffffffff810f2508>] ? vma_link+0x88/0xe0 >> [<ffffffff810ee6a8>] handle_mm_fault+0x138/0x260 >> [<ffffffff8102709d>] do_page_fault+0x13d/0x460 >> [<ffffffff810f46fc>] ? do_mmap_pgoff+0x3dc/0x430 >> [<ffffffff815b61ff>] page_fault+0x1f/0x30 >> ---[ end trace 8817670349022007 ]--- >> apache2 invoked oom-killer: gfp_mask=0x0, order=0, oom_adj=0, oom_score_adj=0 >> apache2 cpuset=uid mems_allowed=0 >> Pid: 3545, comm: apache2 Tainted: G W 3.2.37-grsec #1 >> Call Trace: >> [<ffffffff810ccd2e>] dump_header+0x7e/0x1e0 >> [<ffffffff810ccc2f>] ? find_lock_task_mm+0x2f/0x70 >> [<ffffffff810cd1f5>] oom_kill_process+0x85/0x2a0 >> [<ffffffff810cd8a5>] out_of_memory+0xe5/0x200 >> [<ffffffff810cda7d>] pagefault_out_of_memory+0xbd/0x110 >> [<ffffffff81026e76>] mm_fault_error+0xb6/0x1a0 >> [<ffffffff8102734e>] do_page_fault+0x3ee/0x460 >> [<ffffffff810f46fc>] ? do_mmap_pgoff+0x3dc/0x430 >> [<ffffffff815b61ff>] page_fault+0x1f/0x30 >> >> The first trace comes from the debugging WARN and it clearly points to >> a file fault path. __do_fault pre-charges a page in case we need to >> do CoW (copy-on-write) for the returned page. This one falls back to >> memcg OOM and never returns ENOMEM as I have mentioned earlier. >> However, the fs fault handler (filemap_fault here) can fallback to >> page_cache_read if the readahead (do_sync_mmap_readahead) fails >> to get page to the page cache. And we can see this happening in >> the first trace. page_cache_read then calls add_to_page_cache_lru >> and eventually gets to add_to_page_cache_locked which calls >> mem_cgroup_cache_charge_no_oom so we will get ENOMEM if oom should >> happen. This ENOMEM gets to the fault handler and kaboom. >> > > Hmm. do we need to increase the "limit" virtually at memcg oom until > the oom-killed process dies ? Here is my naive idea... == From 1a46318cf89e7df94bd4844f29105b61dacf335b Mon Sep 17 00:00:00 2001 From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Date: Fri, 8 Feb 2013 10:43:52 +0900 Subject: [PATCH] [Don't Apply][PATCH] memcg relax resource at OOM situation. When an OOM happens, a task is killed and resources will be freed. A problem here is that a task, which is oom-killed, may wait for some other resource in which memory resource is required. Some thread waits for free memory may holds some mutex and oom-killed process wait for the mutex. To avoid this, relaxing charged memory by giving virtual resource can be a help. The system can get back it at uncharge(). This is a sample native implementation. Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> --- mm/memcontrol.c | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 73 insertions(+), 6 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 25ac5f4..4dea49a 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -301,6 +301,9 @@ struct mem_cgroup { /* set when res.limit == memsw.limit */ bool memsw_is_minimum; + /* extra resource at emergency situation */ + unsigned long loan; + spinlock_t loan_lock; /* protect arrays of thresholds */ struct mutex thresholds_lock; @@ -2034,6 +2037,61 @@ static int mem_cgroup_soft_reclaim(struct mem_cgroup *root_memcg, mem_cgroup_iter_break(root_memcg, victim); return total; } +/* + * When a memcg is in OOM situation, this lack of resource may cause deadlock + * because of complicated lock dependency(i_mutex...). To avoid that, we + * need extra resource or avoid charging. + * + * A memcg can request resource in an emergency state. We call it as loan. + * A memcg will return a loan when it does uncharge resource. We disallow + * double-loan and moving task to other groups until the loan is fully + * returned. + * + * Note: the problem here is that we cannot know what amount resouce should + * be necessary to exiting an emergency state..... + */ +#define LOAN_MAX (2 * 1024 * 1024) + +static void mem_cgroup_make_loan(struct mem_cgroup *memcg) +{ + u64 usage; + unsigned long amount; + + amount = LOAN_MAX; + + usage = res_counter_read_u64(&memcg->res, RES_USAGE); + if (amount > usage /2 ) + amount = usage / 2; + spin_lock(&memcg->loan_lock); + if (memcg->loan) { + spin_unlock(&memcg->loan_lock); + return; + } + memcg->loan = amount; + res_counter_uncharge(&memcg->res, amount); + if (do_swap_account) + res_counter_uncharge(&memcg->memsw, amount); + spin_unlock(&memcg->loan_lock); +} + +/* return amount of free resource which can be uncharged */ +static unsigned long +mem_cgroup_may_return_loan(struct mem_cgroup *memcg, unsigned long val) +{ + unsigned long tmp; + /* we don't care small race here */ + if (unlikely(!memcg->loan)) + return val; + spin_lock(&memcg->loan_lock); + if (memcg->loan) { + tmp = min(memcg->loan, val); + memcg->loan -= tmp; + val -= tmp; + } + spin_unlock(&memcg->loan_lock); + return val; +} + /* * Check OOM-Killer is already running under our hierarchy. @@ -2182,6 +2240,7 @@ static bool mem_cgroup_handle_oom(struct mem_cgroup *memcg, gfp_t mask, if (need_to_kill) { finish_wait(&memcg_oom_waitq, &owait.wait); mem_cgroup_out_of_memory(memcg, mask, order); + mem_cgroup_make_loan(memcg); } else { schedule(); finish_wait(&memcg_oom_waitq, &owait.wait); @@ -2748,6 +2807,8 @@ static void __mem_cgroup_cancel_charge(struct mem_cgroup *memcg, if (!mem_cgroup_is_root(memcg)) { unsigned long bytes = nr_pages * PAGE_SIZE; + bytes = mem_cgroup_may_return_loan(memcg, bytes); + res_counter_uncharge(&memcg->res, bytes); if (do_swap_account) res_counter_uncharge(&memcg->memsw, bytes); @@ -3989,6 +4050,7 @@ static void mem_cgroup_do_uncharge(struct mem_cgroup *memcg, { struct memcg_batch_info *batch = NULL; bool uncharge_memsw = true; + unsigned long val; /* If swapout, usage of swap doesn't decrease */ if (!do_swap_account || ctype == MEM_CGROUP_CHARGE_TYPE_SWAPOUT) @@ -4029,9 +4091,11 @@ static void mem_cgroup_do_uncharge(struct mem_cgroup *memcg, batch->memsw_nr_pages++; return; direct_uncharge: - res_counter_uncharge(&memcg->res, nr_pages * PAGE_SIZE); + val = nr_pages * PAGE_SIZE; + val = mem_cgroup_may_return_loan(memcg, val); + res_counter_uncharge(&memcg->res, val); if (uncharge_memsw) - res_counter_uncharge(&memcg->memsw, nr_pages * PAGE_SIZE); + res_counter_uncharge(&memcg->memsw, val); if (unlikely(batch->memcg != memcg)) memcg_oom_recover(memcg); } @@ -4182,6 +4246,7 @@ void mem_cgroup_uncharge_start(void) void mem_cgroup_uncharge_end(void) { struct memcg_batch_info *batch = ¤t->memcg_batch; + unsigned long val; if (!batch->do_batch) return; @@ -4192,16 +4257,16 @@ void mem_cgroup_uncharge_end(void) if (!batch->memcg) return; + val = batch->nr_pages * PAGE_SIZE; + val = mem_cgroup_may_return_loan(batch->memcg, val); /* * This "batch->memcg" is valid without any css_get/put etc... * bacause we hide charges behind us. */ if (batch->nr_pages) - res_counter_uncharge(&batch->memcg->res, - batch->nr_pages * PAGE_SIZE); + res_counter_uncharge(&batch->memcg->res, val); if (batch->memsw_nr_pages) - res_counter_uncharge(&batch->memcg->memsw, - batch->memsw_nr_pages * PAGE_SIZE); + res_counter_uncharge(&batch->memcg->memsw, val); memcg_oom_recover(batch->memcg); /* forget this pointer (for sanity check) */ batch->memcg = NULL; @@ -6291,6 +6356,8 @@ mem_cgroup_css_alloc(struct cgroup *cont) memcg->move_charge_at_immigrate = 0; mutex_init(&memcg->thresholds_lock); spin_lock_init(&memcg->move_lock); + memcg->loan = 0; + spin_lock_init(&memcg->loan_lock); return &memcg->css; -- 1.7.10.2 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> To: Michal Hocko <mhocko@suse.cz> Cc: azurIt <azurit@pobox.sk>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, cgroups mailinglist <cgroups@vger.kernel.org>, Johannes Weiner <hannes@cmpxchg.org> Subject: Re: [PATCH for 3.2.34] memcg: do not trigger OOM from add_to_page_cache_locked Date: Fri, 08 Feb 2013 10:40:13 +0900 [thread overview] Message-ID: <5114577D.70608@jp.fujitsu.com> (raw) In-Reply-To: <51138999.3090006@jp.fujitsu.com> (2013/02/07 20:01), Kamezawa Hiroyuki wrote: > (2013/02/06 23:01), Michal Hocko wrote: >> On Wed 06-02-13 02:17:21, azurIt wrote: >>>> 5-memcg-fix-1.patch is not complete. It doesn't contain the folloup I >>>> mentioned in a follow up email. Here is the full patch: >>> >>> >>> Here is the log where OOM, again, killed MySQL server [search for "(mysqld)"]: >>> http://www.watchdog.sk/lkml/oom_mysqld6 >> >> [...] >> WARNING: at mm/memcontrol.c:2409 T.1149+0x2d9/0x610() >> Hardware name: S5000VSA >> gfp_mask:4304 nr_pages:1 oom:0 ret:2 >> Pid: 3545, comm: apache2 Tainted: G W 3.2.37-grsec #1 >> Call Trace: >> [<ffffffff8105502a>] warn_slowpath_common+0x7a/0xb0 >> [<ffffffff81055116>] warn_slowpath_fmt+0x46/0x50 >> [<ffffffff81108163>] ? mem_cgroup_margin+0x73/0xa0 >> [<ffffffff8110b6f9>] T.1149+0x2d9/0x610 >> [<ffffffff812af298>] ? blk_finish_plug+0x18/0x50 >> [<ffffffff8110c6b4>] mem_cgroup_cache_charge+0xc4/0xf0 >> [<ffffffff810ca6bf>] add_to_page_cache_locked+0x4f/0x140 >> [<ffffffff810ca7d2>] add_to_page_cache_lru+0x22/0x50 >> [<ffffffff810cad32>] filemap_fault+0x252/0x4f0 >> [<ffffffff810eab18>] __do_fault+0x78/0x5a0 >> [<ffffffff810edcb4>] handle_pte_fault+0x84/0x940 >> [<ffffffff810e2460>] ? vma_prio_tree_insert+0x30/0x50 >> [<ffffffff810f2508>] ? vma_link+0x88/0xe0 >> [<ffffffff810ee6a8>] handle_mm_fault+0x138/0x260 >> [<ffffffff8102709d>] do_page_fault+0x13d/0x460 >> [<ffffffff810f46fc>] ? do_mmap_pgoff+0x3dc/0x430 >> [<ffffffff815b61ff>] page_fault+0x1f/0x30 >> ---[ end trace 8817670349022007 ]--- >> apache2 invoked oom-killer: gfp_mask=0x0, order=0, oom_adj=0, oom_score_adj=0 >> apache2 cpuset=uid mems_allowed=0 >> Pid: 3545, comm: apache2 Tainted: G W 3.2.37-grsec #1 >> Call Trace: >> [<ffffffff810ccd2e>] dump_header+0x7e/0x1e0 >> [<ffffffff810ccc2f>] ? find_lock_task_mm+0x2f/0x70 >> [<ffffffff810cd1f5>] oom_kill_process+0x85/0x2a0 >> [<ffffffff810cd8a5>] out_of_memory+0xe5/0x200 >> [<ffffffff810cda7d>] pagefault_out_of_memory+0xbd/0x110 >> [<ffffffff81026e76>] mm_fault_error+0xb6/0x1a0 >> [<ffffffff8102734e>] do_page_fault+0x3ee/0x460 >> [<ffffffff810f46fc>] ? do_mmap_pgoff+0x3dc/0x430 >> [<ffffffff815b61ff>] page_fault+0x1f/0x30 >> >> The first trace comes from the debugging WARN and it clearly points to >> a file fault path. __do_fault pre-charges a page in case we need to >> do CoW (copy-on-write) for the returned page. This one falls back to >> memcg OOM and never returns ENOMEM as I have mentioned earlier. >> However, the fs fault handler (filemap_fault here) can fallback to >> page_cache_read if the readahead (do_sync_mmap_readahead) fails >> to get page to the page cache. And we can see this happening in >> the first trace. page_cache_read then calls add_to_page_cache_lru >> and eventually gets to add_to_page_cache_locked which calls >> mem_cgroup_cache_charge_no_oom so we will get ENOMEM if oom should >> happen. This ENOMEM gets to the fault handler and kaboom. >> > > Hmm. do we need to increase the "limit" virtually at memcg oom until > the oom-killed process dies ? Here is my naive idea... == From 1a46318cf89e7df94bd4844f29105b61dacf335b Mon Sep 17 00:00:00 2001 From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Date: Fri, 8 Feb 2013 10:43:52 +0900 Subject: [PATCH] [Don't Apply][PATCH] memcg relax resource at OOM situation. When an OOM happens, a task is killed and resources will be freed. A problem here is that a task, which is oom-killed, may wait for some other resource in which memory resource is required. Some thread waits for free memory may holds some mutex and oom-killed process wait for the mutex. To avoid this, relaxing charged memory by giving virtual resource can be a help. The system can get back it at uncharge(). This is a sample native implementation. Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> --- mm/memcontrol.c | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 73 insertions(+), 6 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 25ac5f4..4dea49a 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -301,6 +301,9 @@ struct mem_cgroup { /* set when res.limit == memsw.limit */ bool memsw_is_minimum; + /* extra resource at emergency situation */ + unsigned long loan; + spinlock_t loan_lock; /* protect arrays of thresholds */ struct mutex thresholds_lock; @@ -2034,6 +2037,61 @@ static int mem_cgroup_soft_reclaim(struct mem_cgroup *root_memcg, mem_cgroup_iter_break(root_memcg, victim); return total; } +/* + * When a memcg is in OOM situation, this lack of resource may cause deadlock + * because of complicated lock dependency(i_mutex...). To avoid that, we + * need extra resource or avoid charging. + * + * A memcg can request resource in an emergency state. We call it as loan. + * A memcg will return a loan when it does uncharge resource. We disallow + * double-loan and moving task to other groups until the loan is fully + * returned. + * + * Note: the problem here is that we cannot know what amount resouce should + * be necessary to exiting an emergency state..... + */ +#define LOAN_MAX (2 * 1024 * 1024) + +static void mem_cgroup_make_loan(struct mem_cgroup *memcg) +{ + u64 usage; + unsigned long amount; + + amount = LOAN_MAX; + + usage = res_counter_read_u64(&memcg->res, RES_USAGE); + if (amount > usage /2 ) + amount = usage / 2; + spin_lock(&memcg->loan_lock); + if (memcg->loan) { + spin_unlock(&memcg->loan_lock); + return; + } + memcg->loan = amount; + res_counter_uncharge(&memcg->res, amount); + if (do_swap_account) + res_counter_uncharge(&memcg->memsw, amount); + spin_unlock(&memcg->loan_lock); +} + +/* return amount of free resource which can be uncharged */ +static unsigned long +mem_cgroup_may_return_loan(struct mem_cgroup *memcg, unsigned long val) +{ + unsigned long tmp; + /* we don't care small race here */ + if (unlikely(!memcg->loan)) + return val; + spin_lock(&memcg->loan_lock); + if (memcg->loan) { + tmp = min(memcg->loan, val); + memcg->loan -= tmp; + val -= tmp; + } + spin_unlock(&memcg->loan_lock); + return val; +} + /* * Check OOM-Killer is already running under our hierarchy. @@ -2182,6 +2240,7 @@ static bool mem_cgroup_handle_oom(struct mem_cgroup *memcg, gfp_t mask, if (need_to_kill) { finish_wait(&memcg_oom_waitq, &owait.wait); mem_cgroup_out_of_memory(memcg, mask, order); + mem_cgroup_make_loan(memcg); } else { schedule(); finish_wait(&memcg_oom_waitq, &owait.wait); @@ -2748,6 +2807,8 @@ static void __mem_cgroup_cancel_charge(struct mem_cgroup *memcg, if (!mem_cgroup_is_root(memcg)) { unsigned long bytes = nr_pages * PAGE_SIZE; + bytes = mem_cgroup_may_return_loan(memcg, bytes); + res_counter_uncharge(&memcg->res, bytes); if (do_swap_account) res_counter_uncharge(&memcg->memsw, bytes); @@ -3989,6 +4050,7 @@ static void mem_cgroup_do_uncharge(struct mem_cgroup *memcg, { struct memcg_batch_info *batch = NULL; bool uncharge_memsw = true; + unsigned long val; /* If swapout, usage of swap doesn't decrease */ if (!do_swap_account || ctype == MEM_CGROUP_CHARGE_TYPE_SWAPOUT) @@ -4029,9 +4091,11 @@ static void mem_cgroup_do_uncharge(struct mem_cgroup *memcg, batch->memsw_nr_pages++; return; direct_uncharge: - res_counter_uncharge(&memcg->res, nr_pages * PAGE_SIZE); + val = nr_pages * PAGE_SIZE; + val = mem_cgroup_may_return_loan(memcg, val); + res_counter_uncharge(&memcg->res, val); if (uncharge_memsw) - res_counter_uncharge(&memcg->memsw, nr_pages * PAGE_SIZE); + res_counter_uncharge(&memcg->memsw, val); if (unlikely(batch->memcg != memcg)) memcg_oom_recover(memcg); } @@ -4182,6 +4246,7 @@ void mem_cgroup_uncharge_start(void) void mem_cgroup_uncharge_end(void) { struct memcg_batch_info *batch = ¤t->memcg_batch; + unsigned long val; if (!batch->do_batch) return; @@ -4192,16 +4257,16 @@ void mem_cgroup_uncharge_end(void) if (!batch->memcg) return; + val = batch->nr_pages * PAGE_SIZE; + val = mem_cgroup_may_return_loan(batch->memcg, val); /* * This "batch->memcg" is valid without any css_get/put etc... * bacause we hide charges behind us. */ if (batch->nr_pages) - res_counter_uncharge(&batch->memcg->res, - batch->nr_pages * PAGE_SIZE); + res_counter_uncharge(&batch->memcg->res, val); if (batch->memsw_nr_pages) - res_counter_uncharge(&batch->memcg->memsw, - batch->memsw_nr_pages * PAGE_SIZE); + res_counter_uncharge(&batch->memcg->memsw, val); memcg_oom_recover(batch->memcg); /* forget this pointer (for sanity check) */ batch->memcg = NULL; @@ -6291,6 +6356,8 @@ mem_cgroup_css_alloc(struct cgroup *cont) memcg->move_charge_at_immigrate = 0; mutex_init(&memcg->thresholds_lock); spin_lock_init(&memcg->move_lock); + memcg->loan = 0; + spin_lock_init(&memcg->loan_lock); return &memcg->css; -- 1.7.10.2
next prev parent reply other threads:[~2013-02-08 1:40 UTC|newest]
Thread overview: 444+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-21 19:02 memory-cgroup bug azurIt
2012-11-22 0:26 ` Kamezawa Hiroyuki
2012-11-22 0:26 ` Kamezawa Hiroyuki
2012-11-22 9:36 ` azurIt
2012-11-22 9:36 ` azurIt
2012-11-22 21:45 ` Michal Hocko
2012-11-22 21:45 ` Michal Hocko
2012-11-22 15:24 ` Michal Hocko
2012-11-22 15:24 ` Michal Hocko
2012-11-22 18:05 ` azurIt
2012-11-22 18:05 ` azurIt
2012-11-22 21:42 ` Michal Hocko
2012-11-22 21:42 ` Michal Hocko
2012-11-22 22:34 ` azurIt
2012-11-22 22:34 ` azurIt
[not found] ` <20121122233434.3D5E35E6-Rm0zKEqwvD4@public.gmane.org>
2012-11-23 7:40 ` Michal Hocko
2012-11-23 7:40 ` Michal Hocko
2012-11-23 7:40 ` Michal Hocko
[not found] ` <20121123074023.GA24698-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-11-23 9:21 ` azurIt
2012-11-23 9:21 ` azurIt
2012-11-23 9:21 ` azurIt
2012-11-23 9:28 ` Michal Hocko
2012-11-23 9:28 ` Michal Hocko
[not found] ` <20121123092829.GE24698-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-11-23 9:44 ` azurIt
2012-11-23 9:44 ` azurIt
2012-11-23 9:44 ` azurIt
[not found] ` <20121123104423.338C7725-Rm0zKEqwvD4@public.gmane.org>
2012-11-23 10:10 ` Michal Hocko
2012-11-23 10:10 ` Michal Hocko
2012-11-23 10:10 ` Michal Hocko
2012-11-23 9:34 ` Glauber Costa
2012-11-23 9:34 ` Glauber Costa
2012-11-23 10:04 ` Michal Hocko
2012-11-23 10:04 ` Michal Hocko
[not found] ` <20121123100438.GF24698-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-11-23 14:59 ` azurIt
2012-11-23 14:59 ` azurIt
2012-11-23 14:59 ` azurIt
[not found] ` <20121123155904.490039C5-Rm0zKEqwvD4@public.gmane.org>
2012-11-25 10:17 ` Michal Hocko
2012-11-25 10:17 ` Michal Hocko
2012-11-25 10:17 ` Michal Hocko
2012-11-25 12:39 ` azurIt
2012-11-25 12:39 ` azurIt
[not found] ` <20121125133953.AD1B2F0A-Rm0zKEqwvD4@public.gmane.org>
2012-11-25 13:02 ` Michal Hocko
2012-11-25 13:02 ` Michal Hocko
2012-11-25 13:02 ` Michal Hocko
[not found] ` <20121125130208.GC10623-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-11-25 13:27 ` azurIt
2012-11-25 13:27 ` azurIt
2012-11-25 13:27 ` azurIt
[not found] ` <20121125142709.19F4E8C2-Rm0zKEqwvD4@public.gmane.org>
2012-11-25 13:44 ` Michal Hocko
2012-11-25 13:44 ` Michal Hocko
2012-11-25 13:44 ` Michal Hocko
2012-11-25 0:10 ` azurIt
2012-11-25 0:10 ` azurIt
2012-11-25 0:10 ` azurIt
2012-11-25 12:05 ` Michal Hocko
2012-11-25 12:05 ` Michal Hocko
2012-11-25 12:36 ` azurIt
2012-11-25 12:36 ` azurIt
2012-11-25 13:55 ` Michal Hocko
2012-11-25 13:55 ` Michal Hocko
2012-11-26 0:38 ` azurIt
2012-11-26 0:38 ` azurIt
[not found] ` <20121126013855.AF118F5E-Rm0zKEqwvD4@public.gmane.org>
2012-11-26 7:57 ` Michal Hocko
2012-11-26 7:57 ` Michal Hocko
2012-11-26 7:57 ` Michal Hocko
2012-11-26 13:18 ` [PATCH -mm] memcg: do not trigger OOM from add_to_page_cache_locked Michal Hocko
2012-11-26 13:18 ` Michal Hocko
2012-11-26 13:18 ` Michal Hocko
2012-11-26 17:46 ` Johannes Weiner
2012-11-26 17:46 ` Johannes Weiner
2012-11-26 18:04 ` Michal Hocko
2012-11-26 18:04 ` Michal Hocko
[not found] ` <20121126180444.GA12602-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-11-26 18:24 ` Johannes Weiner
2012-11-26 18:24 ` Johannes Weiner
2012-11-26 18:24 ` Johannes Weiner
[not found] ` <20121126182421.GB2301-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2012-11-26 19:03 ` Michal Hocko
2012-11-26 19:03 ` Michal Hocko
2012-11-26 19:03 ` Michal Hocko
[not found] ` <20121126190329.GB12602-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-11-26 19:29 ` Johannes Weiner
2012-11-26 19:29 ` Johannes Weiner
2012-11-26 19:29 ` Johannes Weiner
[not found] ` <20121126192941.GC2301-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2012-11-26 20:08 ` Michal Hocko
2012-11-26 20:08 ` Michal Hocko
2012-11-26 20:08 ` Michal Hocko
2012-11-26 20:19 ` Johannes Weiner
2012-11-26 20:19 ` Johannes Weiner
[not found] ` <20121126201918.GD2301-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2012-11-26 20:46 ` azurIt
2012-11-26 20:46 ` azurIt
2012-11-26 20:46 ` azurIt
2012-11-26 20:53 ` Johannes Weiner
2012-11-26 20:53 ` Johannes Weiner
2012-11-26 22:06 ` Michal Hocko
2012-11-26 22:06 ` Michal Hocko
2012-11-26 22:06 ` Michal Hocko
[not found] ` <20121126131837.GC17860-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-11-26 13:21 ` [PATCH for 3.2.34] " Michal Hocko
2012-11-26 13:21 ` Michal Hocko
2012-11-26 13:21 ` Michal Hocko
2012-11-26 21:28 ` azurIt
2012-11-26 21:28 ` azurIt
[not found] ` <20121126132149.GD17860-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-11-30 1:45 ` azurIt
2012-11-30 1:45 ` azurIt
2012-11-30 1:45 ` azurIt
2012-11-30 2:29 ` azurIt
2012-11-30 2:29 ` azurIt
[not found] ` <20121130032918.59B3F780-Rm0zKEqwvD4@public.gmane.org>
2012-11-30 12:45 ` Michal Hocko
2012-11-30 12:45 ` Michal Hocko
2012-11-30 12:45 ` Michal Hocko
[not found] ` <20121130124506.GH29317-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-11-30 12:53 ` azurIt
2012-11-30 12:53 ` azurIt
2012-11-30 12:53 ` azurIt
2012-11-30 13:44 ` azurIt
2012-11-30 13:44 ` azurIt
[not found] ` <20121130144427.51A09169-Rm0zKEqwvD4@public.gmane.org>
2012-11-30 14:44 ` Michal Hocko
2012-11-30 14:44 ` Michal Hocko
2012-11-30 14:44 ` Michal Hocko
[not found] ` <20121130144431.GI29317-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-11-30 15:03 ` Michal Hocko
2012-11-30 15:03 ` Michal Hocko
2012-11-30 15:03 ` Michal Hocko
2012-11-30 15:37 ` Michal Hocko
2012-11-30 15:37 ` Michal Hocko
2012-11-30 15:08 ` azurIt
2012-11-30 15:08 ` azurIt
2012-11-30 15:39 ` Michal Hocko
2012-11-30 15:39 ` Michal Hocko
[not found] ` <20121130153942.GL29317-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-11-30 15:59 ` azurIt
2012-11-30 15:59 ` azurIt
2012-11-30 15:59 ` azurIt
2012-11-30 16:19 ` Michal Hocko
2012-11-30 16:19 ` Michal Hocko
2012-11-30 16:26 ` azurIt
2012-11-30 16:26 ` azurIt
[not found] ` <20121130172651.B6917602-Rm0zKEqwvD4@public.gmane.org>
2012-11-30 16:53 ` Michal Hocko
2012-11-30 16:53 ` Michal Hocko
2012-11-30 16:53 ` Michal Hocko
2012-11-30 20:43 ` azurIt
2012-11-30 20:43 ` azurIt
2012-12-03 15:16 ` Michal Hocko
2012-12-03 15:16 ` Michal Hocko
[not found] ` <20121203151601.GA17093-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-12-05 1:36 ` azurIt
2012-12-05 1:36 ` azurIt
2012-12-05 1:36 ` azurIt
[not found] ` <20121205023644.18C3006B-Rm0zKEqwvD4@public.gmane.org>
2012-12-05 14:17 ` Michal Hocko
2012-12-05 14:17 ` Michal Hocko
2012-12-05 14:17 ` Michal Hocko
[not found] ` <20121205141722.GA9714-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-12-06 0:29 ` azurIt
2012-12-06 0:29 ` azurIt
2012-12-06 0:29 ` azurIt
[not found] ` <20121206012924.FE077FD7-Rm0zKEqwvD4@public.gmane.org>
2012-12-06 9:54 ` Michal Hocko
2012-12-06 9:54 ` Michal Hocko
2012-12-06 9:54 ` Michal Hocko
2012-12-06 10:12 ` azurIt
2012-12-06 10:12 ` azurIt
2012-12-06 17:06 ` Michal Hocko
2012-12-06 17:06 ` Michal Hocko
[not found] ` <20121206095423.GB10931-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-12-10 1:20 ` azurIt
2012-12-10 1:20 ` azurIt
2012-12-10 1:20 ` azurIt
[not found] ` <20121210022038.E6570D37-Rm0zKEqwvD4@public.gmane.org>
2012-12-10 9:43 ` Michal Hocko
2012-12-10 9:43 ` Michal Hocko
2012-12-10 9:43 ` Michal Hocko
[not found] ` <20121210094318.GA6777-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-12-10 10:18 ` azurIt
2012-12-10 10:18 ` azurIt
2012-12-10 10:18 ` azurIt
[not found] ` <20121210111817.F697F53E-Rm0zKEqwvD4@public.gmane.org>
2012-12-10 15:52 ` Michal Hocko
2012-12-10 15:52 ` Michal Hocko
2012-12-10 15:52 ` Michal Hocko
2012-12-10 17:18 ` azurIt
2012-12-10 17:18 ` azurIt
2012-12-17 1:34 ` azurIt
2012-12-17 1:34 ` azurIt
2012-12-17 16:32 ` Michal Hocko
2012-12-17 16:32 ` Michal Hocko
2012-12-17 18:23 ` azurIt
2012-12-17 18:23 ` azurIt
[not found] ` <20121217192301.829A7020-Rm0zKEqwvD4@public.gmane.org>
2012-12-17 19:55 ` Michal Hocko
2012-12-17 19:55 ` Michal Hocko
2012-12-17 19:55 ` Michal Hocko
[not found] ` <20121217195510.GA16375-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-12-18 14:22 ` azurIt
2012-12-18 14:22 ` azurIt
2012-12-18 14:22 ` azurIt
2012-12-18 15:20 ` Michal Hocko
2012-12-18 15:20 ` Michal Hocko
[not found] ` <20121218152004.GA25208-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-12-24 13:25 ` azurIt
2012-12-24 13:25 ` azurIt
2012-12-24 13:25 ` azurIt
[not found] ` <20121224142526.020165D3-Rm0zKEqwvD4@public.gmane.org>
2012-12-28 16:22 ` Michal Hocko
2012-12-28 16:22 ` Michal Hocko
2012-12-28 16:22 ` Michal Hocko
[not found] ` <20121228162209.GA1455-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-12-30 1:09 ` azurIt
2012-12-30 1:09 ` azurIt
2012-12-30 1:09 ` azurIt
2012-12-30 11:08 ` Michal Hocko
2012-12-30 11:08 ` Michal Hocko
[not found] ` <20121230110815.GA12940-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-01-25 15:07 ` azurIt
2013-01-25 15:07 ` azurIt
2013-01-25 15:07 ` azurIt
2013-01-25 16:31 ` Michal Hocko
2013-01-25 16:31 ` Michal Hocko
2013-01-25 16:31 ` Michal Hocko
[not found] ` <20130125163130.GF4721-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-02-05 13:49 ` Michal Hocko
2013-02-05 13:49 ` Michal Hocko
2013-02-05 13:49 ` Michal Hocko
2013-02-05 14:49 ` azurIt
2013-02-05 14:49 ` azurIt
2013-02-05 16:09 ` Michal Hocko
2013-02-05 16:09 ` Michal Hocko
2013-02-05 16:09 ` Michal Hocko
2013-02-05 16:46 ` azurIt
2013-02-05 16:46 ` azurIt
2013-02-05 16:48 ` Greg Thelen
2013-02-05 16:48 ` Greg Thelen
2013-02-05 17:46 ` Michal Hocko
2013-02-05 17:46 ` Michal Hocko
2013-02-05 18:09 ` Greg Thelen
2013-02-05 18:09 ` Greg Thelen
[not found] ` <xr93a9ri4op6.fsf-aSPv4SP+Du0KgorLzL7FmE7CuiCeIGUxQQ4Iyu8u01E@public.gmane.org>
2013-02-05 18:59 ` Michal Hocko
2013-02-05 18:59 ` Michal Hocko
2013-02-05 18:59 ` Michal Hocko
2013-02-08 4:27 ` Greg Thelen
2013-02-08 4:27 ` Greg Thelen
[not found] ` <xr93ip63ig6j.fsf-aSPv4SP+Du0KgorLzL7FmE7CuiCeIGUxQQ4Iyu8u01E@public.gmane.org>
2013-02-08 16:29 ` Michal Hocko
2013-02-08 16:29 ` Michal Hocko
2013-02-08 16:29 ` Michal Hocko
2013-02-08 16:40 ` Michal Hocko
2013-02-08 16:40 ` Michal Hocko
2013-02-06 1:17 ` azurIt
2013-02-06 1:17 ` azurIt
[not found] ` <20130206021721.1AE9E3C7-Rm0zKEqwvD4@public.gmane.org>
2013-02-06 14:01 ` Michal Hocko
2013-02-06 14:01 ` Michal Hocko
2013-02-06 14:01 ` Michal Hocko
[not found] ` <20130206140119.GD10254-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-02-06 14:22 ` Michal Hocko
2013-02-06 14:22 ` Michal Hocko
2013-02-06 14:22 ` Michal Hocko
[not found] ` <20130206142219.GF10254-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-02-06 16:00 ` [PATCH for 3.2.34] memcg: do not trigger OOM if PF_NO_MEMCG_OOM is set Michal Hocko
2013-02-06 16:00 ` Michal Hocko
2013-02-06 16:00 ` Michal Hocko
2013-02-08 5:03 ` azurIt
2013-02-08 5:03 ` azurIt
2013-02-08 5:03 ` azurIt
2013-02-08 9:44 ` Michal Hocko
2013-02-08 9:44 ` Michal Hocko
2013-02-08 11:02 ` azurIt
2013-02-08 11:02 ` azurIt
[not found] ` <20130208120249.FD733220-Rm0zKEqwvD4@public.gmane.org>
2013-02-08 12:38 ` Michal Hocko
2013-02-08 12:38 ` Michal Hocko
2013-02-08 12:38 ` Michal Hocko
2013-02-08 13:56 ` azurIt
2013-02-08 13:56 ` azurIt
[not found] ` <20130208145616.FB78CE24-Rm0zKEqwvD4@public.gmane.org>
2013-02-08 14:47 ` Michal Hocko
2013-02-08 14:47 ` Michal Hocko
2013-02-08 14:47 ` Michal Hocko
2013-02-08 15:24 ` Michal Hocko
2013-02-08 15:24 ` Michal Hocko
2013-02-08 15:24 ` Michal Hocko
[not found] ` <20130208152402.GD7557-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-02-08 15:58 ` azurIt
2013-02-08 15:58 ` azurIt
2013-02-08 15:58 ` azurIt
[not found] ` <20130208165805.8908B143-Rm0zKEqwvD4@public.gmane.org>
2013-02-08 17:10 ` Michal Hocko
2013-02-08 17:10 ` Michal Hocko
2013-02-08 17:10 ` Michal Hocko
2013-02-08 21:02 ` azurIt
2013-02-08 21:02 ` azurIt
[not found] ` <20130208220243.EDEE0825-Rm0zKEqwvD4@public.gmane.org>
2013-02-10 15:03 ` Michal Hocko
2013-02-10 15:03 ` Michal Hocko
2013-02-10 15:03 ` Michal Hocko
[not found] ` <20130210150310.GA9504-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-02-10 16:46 ` azurIt
2013-02-10 16:46 ` azurIt
2013-02-10 16:46 ` azurIt
2013-02-11 11:22 ` Michal Hocko
2013-02-11 11:22 ` Michal Hocko
2013-02-11 11:22 ` Michal Hocko
[not found] ` <20130211112240.GC19922-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-02-22 8:23 ` azurIt
2013-02-22 8:23 ` azurIt
2013-02-22 8:23 ` azurIt
[not found] ` <20130222092332.4001E4B6-Rm0zKEqwvD4@public.gmane.org>
2013-02-22 12:52 ` Michal Hocko
2013-02-22 12:52 ` Michal Hocko
2013-02-22 12:52 ` Michal Hocko
2013-02-22 12:54 ` azurIt
2013-02-22 12:54 ` azurIt
[not found] ` <20130222135442.ADFFF498-Rm0zKEqwvD4@public.gmane.org>
2013-02-22 13:00 ` Michal Hocko
2013-02-22 13:00 ` Michal Hocko
2013-02-22 13:00 ` Michal Hocko
2013-06-06 16:04 ` Michal Hocko
2013-06-06 16:04 ` Michal Hocko
2013-06-06 16:04 ` Michal Hocko
2013-06-06 16:16 ` azurIt
2013-06-06 16:16 ` azurIt
2013-06-06 16:16 ` azurIt
2013-06-07 13:11 ` [PATCH for 3.2] memcg: do not trap chargers with full callstack on OOM Michal Hocko
2013-06-07 13:11 ` Michal Hocko
2013-06-07 13:11 ` Michal Hocko
2013-06-17 10:21 ` azurIt
2013-06-17 10:21 ` azurIt
2013-06-19 13:26 ` Michal Hocko
2013-06-19 13:26 ` Michal Hocko
2013-06-22 20:09 ` azurIt
2013-06-22 20:09 ` azurIt
[not found] ` <20130622220958.D10567A4-Rm0zKEqwvD4@public.gmane.org>
2013-06-24 20:13 ` Johannes Weiner
2013-06-24 20:13 ` Johannes Weiner
2013-06-24 20:13 ` Johannes Weiner
[not found] ` <20130624201345.GA21822-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2013-06-28 10:06 ` azurIt
2013-06-28 10:06 ` azurIt
2013-06-28 10:06 ` azurIt
[not found] ` <20130628120613.6D6CAD21-Rm0zKEqwvD4@public.gmane.org>
2013-07-05 18:17 ` Johannes Weiner
2013-07-05 18:17 ` Johannes Weiner
2013-07-05 18:17 ` Johannes Weiner
2013-07-05 19:02 ` azurIt
2013-07-05 19:02 ` azurIt
[not found] ` <20130705210246.11D2135A-Rm0zKEqwvD4@public.gmane.org>
2013-07-05 19:18 ` Johannes Weiner
2013-07-05 19:18 ` Johannes Weiner
2013-07-05 19:18 ` Johannes Weiner
2013-07-07 23:42 ` azurIt
2013-07-07 23:42 ` azurIt
2013-07-09 13:10 ` Michal Hocko
2013-07-09 13:10 ` Michal Hocko
2013-07-09 13:19 ` azurIt
2013-07-09 13:19 ` azurIt
[not found] ` <20130709151921.5160C199-Rm0zKEqwvD4@public.gmane.org>
2013-07-09 13:54 ` Michal Hocko
2013-07-09 13:54 ` Michal Hocko
2013-07-09 13:54 ` Michal Hocko
2013-07-10 16:25 ` azurIt
2013-07-10 16:25 ` azurIt
2013-07-11 7:25 ` Michal Hocko
2013-07-11 7:25 ` Michal Hocko
2013-07-11 7:25 ` Michal Hocko
2013-07-13 23:26 ` azurIt
2013-07-13 23:26 ` azurIt
2013-07-13 23:26 ` azurIt
2013-07-13 23:51 ` azurIt
2013-07-13 23:51 ` azurIt
[not found] ` <20130714015112.FFCB7AF7-Rm0zKEqwvD4@public.gmane.org>
2013-07-15 15:41 ` Michal Hocko
2013-07-15 15:41 ` Michal Hocko
2013-07-15 15:41 ` Michal Hocko
[not found] ` <20130715154119.GA32435-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-07-15 16:00 ` Michal Hocko
2013-07-15 16:00 ` Michal Hocko
2013-07-15 16:00 ` Michal Hocko
[not found] ` <20130715160006.GB32435-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-07-16 15:35 ` Johannes Weiner
2013-07-16 15:35 ` Johannes Weiner
2013-07-16 15:35 ` Johannes Weiner
[not found] ` <20130716153544.GX17812-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2013-07-16 16:09 ` Michal Hocko
2013-07-16 16:09 ` Michal Hocko
2013-07-16 16:09 ` Michal Hocko
[not found] ` <20130716160905.GA20018-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-07-16 16:48 ` Johannes Weiner
2013-07-16 16:48 ` Johannes Weiner
2013-07-16 16:48 ` Johannes Weiner
2013-07-19 4:21 ` Johannes Weiner
2013-07-19 4:21 ` Johannes Weiner
[not found] ` <20130719042124.GC17812-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2013-07-19 4:22 ` [patch 1/5] mm: invoke oom-killer from remaining unconverted page fault handlers Johannes Weiner
2013-07-19 4:22 ` Johannes Weiner
2013-07-19 4:22 ` Johannes Weiner
2013-07-19 4:24 ` [patch 2/5] mm: pass userspace fault flag to generic fault handler Johannes Weiner
2013-07-19 4:24 ` Johannes Weiner
2013-07-19 4:24 ` Johannes Weiner
2013-07-19 4:25 ` [patch 4/5] memcg: do not trap chargers with full callstack on OOM Johannes Weiner
2013-07-19 4:25 ` Johannes Weiner
2013-07-19 4:25 ` Johannes Weiner
2013-07-19 4:26 ` [patch 5/5] mm: memcontrol: sanity check memcg OOM context unwind Johannes Weiner
2013-07-19 4:26 ` Johannes Weiner
2013-07-19 4:26 ` Johannes Weiner
2013-07-19 8:23 ` [PATCH for 3.2] memcg: do not trap chargers with full callstack on OOM azurIt
2013-07-19 8:23 ` azurIt
2013-07-19 8:23 ` azurIt
2013-07-19 4:25 ` [patch 3/5] x86: finish fault error path with fatal signal Johannes Weiner
2013-07-19 4:25 ` Johannes Weiner
[not found] ` <20130719042502.GF17812-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2013-07-24 20:32 ` Johannes Weiner
2013-07-24 20:32 ` Johannes Weiner
2013-07-24 20:32 ` Johannes Weiner
2013-07-25 20:29 ` KOSAKI Motohiro
2013-07-25 20:29 ` KOSAKI Motohiro
[not found] ` <51F18A99.7000306-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-07-25 21:50 ` Johannes Weiner
2013-07-25 21:50 ` Johannes Weiner
2013-07-25 21:50 ` Johannes Weiner
2013-07-14 17:07 ` [PATCH for 3.2] memcg: do not trap chargers with full callstack on OOM azurIt
2013-07-14 17:07 ` azurIt
2013-07-09 13:00 ` Michal Hocko
2013-07-09 13:00 ` Michal Hocko
2013-07-09 13:00 ` Michal Hocko
[not found] ` <20130709130017.GE20281-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-07-09 13:08 ` Michal Hocko
2013-07-09 13:08 ` Michal Hocko
2013-07-09 13:08 ` Michal Hocko
[not found] ` <20130709130808.GF20281-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-07-09 13:10 ` Michal Hocko
2013-07-09 13:10 ` Michal Hocko
2013-07-09 13:10 ` Michal Hocko
2013-06-24 16:48 ` azurIt
2013-06-24 16:48 ` azurIt
2013-02-22 12:00 ` [PATCH for 3.2.34] memcg: do not trigger OOM if PF_NO_MEMCG_OOM is set azurIt
2013-02-22 12:00 ` azurIt
2013-02-07 11:01 ` [PATCH for 3.2.34] memcg: do not trigger OOM from add_to_page_cache_locked Kamezawa Hiroyuki
2013-02-07 11:01 ` Kamezawa Hiroyuki
[not found] ` <51138999.3090006-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2013-02-07 12:31 ` Michal Hocko
2013-02-07 12:31 ` Michal Hocko
2013-02-07 12:31 ` Michal Hocko
2013-02-08 4:16 ` Kamezawa Hiroyuki
2013-02-08 4:16 ` Kamezawa Hiroyuki
2013-02-08 1:40 ` Kamezawa Hiroyuki [this message]
2013-02-08 1:40 ` Kamezawa Hiroyuki
2013-02-08 1:40 ` Kamezawa Hiroyuki
[not found] ` <5114577D.70608-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2013-02-08 16:01 ` Michal Hocko
2013-02-08 16:01 ` Michal Hocko
2013-02-08 16:01 ` Michal Hocko
[not found] ` <20130205154947.CD6411E2-Rm0zKEqwvD4@public.gmane.org>
2013-02-05 16:31 ` Michal Hocko
2013-02-05 16:31 ` Michal Hocko
2013-02-05 16:31 ` Michal Hocko
2012-12-24 13:38 ` azurIt
2012-12-24 13:38 ` azurIt
2012-12-24 13:38 ` azurIt
2012-12-28 16:35 ` Michal Hocko
2012-12-28 16:35 ` Michal Hocko
2012-11-27 0:05 ` [PATCH -mm] " Kamezawa Hiroyuki
2012-11-27 0:05 ` Kamezawa Hiroyuki
2012-11-27 0:05 ` Kamezawa Hiroyuki
[not found] ` <50B403CA.501-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2012-11-27 9:54 ` Michal Hocko
2012-11-27 9:54 ` Michal Hocko
2012-11-27 9:54 ` Michal Hocko
2012-11-27 19:48 ` Johannes Weiner
2012-11-27 19:48 ` Johannes Weiner
2012-11-27 19:48 ` Johannes Weiner
[not found] ` <20121127194813.GP24381-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2012-11-27 20:54 ` [PATCH -v2 " Michal Hocko
2012-11-27 20:54 ` Michal Hocko
2012-11-27 20:54 ` Michal Hocko
[not found] ` <20121127205431.GA2433-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-11-27 20:59 ` Michal Hocko
2012-11-27 20:59 ` Michal Hocko
2012-11-27 20:59 ` Michal Hocko
[not found] ` <20121127205944.GB2433-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-11-28 15:26 ` Johannes Weiner
2012-11-28 15:26 ` Johannes Weiner
2012-11-28 15:26 ` Johannes Weiner
2012-11-28 16:04 ` Michal Hocko
2012-11-28 16:04 ` Michal Hocko
2012-11-28 16:04 ` Michal Hocko
[not found] ` <20121128160447.GH12309-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-11-28 16:37 ` Johannes Weiner
2012-11-28 16:37 ` Johannes Weiner
2012-11-28 16:37 ` Johannes Weiner
2012-11-28 16:46 ` Michal Hocko
2012-11-28 16:46 ` Michal Hocko
2012-11-28 16:48 ` Michal Hocko
2012-11-28 16:48 ` Michal Hocko
2012-11-28 16:48 ` Michal Hocko
[not found] ` <20121128164824.GC22201-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-11-28 18:44 ` Johannes Weiner
2012-11-28 18:44 ` Johannes Weiner
2012-11-28 18:44 ` Johannes Weiner
2012-11-28 20:20 ` Hugh Dickins
2012-11-28 20:20 ` Hugh Dickins
2012-11-28 20:20 ` Hugh Dickins
2012-11-29 14:05 ` Michal Hocko
2012-11-29 14:05 ` 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=5114577D.70608@jp.fujitsu.com \
--to=kamezawa.hiroyu-+cum20s59erqfuhtdcdx3a@public.gmane.org \
--cc=azurit-Rm0zKEqwvD4@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=mhocko-AlSwsSmVLrQ@public.gmane.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 an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.