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 -mm] memcg: do not trigger OOM from add_to_page_cache_locked
Date: Tue, 27 Nov 2012 09:05:30 +0900 [thread overview]
Message-ID: <50B403CA.501@jp.fujitsu.com> (raw)
In-Reply-To: <20121126131837.GC17860@dhcp22.suse.cz>
(2012/11/26 22:18), Michal Hocko wrote:
> [CCing also Johannes - the thread started here:
> https://lkml.org/lkml/2012/11/21/497]
>
> On Mon 26-11-12 01:38:55, azurIt wrote:
>>> This is hackish but it should help you in this case. Kamezawa, what do
>>> you think about that? Should we generalize this and prepare something
>>> like mem_cgroup_cache_charge_locked which would add __GFP_NORETRY
>>> automatically and use the function whenever we are in a locked context?
>>> To be honest I do not like this very much but nothing more sensible
>>> (without touching non-memcg paths) comes to my mind.
>>
>>
>> I installed kernel with this patch, will report back if problem occurs
>> again OR in few weeks if everything will be ok. Thank you!
>
> Now that I am looking at the patch closer it will not work because it
> depends on other patch which is not merged yet and even that one would
> help on its own because __GFP_NORETRY doesn't break the charge loop.
> Sorry I have missed that...
>
> The patch bellow should help though. (it is based on top of the current
> -mm tree but I will send a backport to 3.2 in the reply as well)
> ---
> From 7796f942d62081ad45726efd90b5292b80e7c690 Mon Sep 17 00:00:00 2001
> From: Michal Hocko <mhocko@suse.cz>
> Date: Mon, 26 Nov 2012 11:47:57 +0100
> Subject: [PATCH] memcg: do not trigger OOM from add_to_page_cache_locked
>
> memcg oom killer might deadlock if the process which falls down to
> mem_cgroup_handle_oom holds a lock which prevents other task to
> terminate because it is blocked on the very same lock.
> This can happen when a write system call needs to allocate a page but
> the allocation hits the memcg hard limit and there is nothing to reclaim
> (e.g. there is no swap or swap limit is hit as well and all cache pages
> have been reclaimed already) and the process selected by memcg OOM
> killer is blocked on i_mutex on the same inode (e.g. truncate it).
>
> Process A
> [<ffffffff811109b8>] do_truncate+0x58/0xa0 # takes i_mutex
> [<ffffffff81121c90>] do_last+0x250/0xa30
> [<ffffffff81122547>] path_openat+0xd7/0x440
> [<ffffffff811229c9>] do_filp_open+0x49/0xa0
> [<ffffffff8110f7d6>] do_sys_open+0x106/0x240
> [<ffffffff8110f950>] sys_open+0x20/0x30
> [<ffffffff815b5926>] system_call_fastpath+0x18/0x1d
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> Process B
> [<ffffffff8110a9c1>] mem_cgroup_handle_oom+0x241/0x3b0
> [<ffffffff8110b5ab>] T.1146+0x5ab/0x5c0
> [<ffffffff8110c22e>] mem_cgroup_cache_charge+0xbe/0xe0
> [<ffffffff810ca28c>] add_to_page_cache_locked+0x4c/0x140
> [<ffffffff810ca3a2>] add_to_page_cache_lru+0x22/0x50
> [<ffffffff810ca45b>] grab_cache_page_write_begin+0x8b/0xe0
> [<ffffffff81193a18>] ext3_write_begin+0x88/0x270
> [<ffffffff810c8fc6>] generic_file_buffered_write+0x116/0x290
> [<ffffffff810cb3cc>] __generic_file_aio_write+0x27c/0x480
> [<ffffffff810cb646>] generic_file_aio_write+0x76/0xf0 # takes ->i_mutex
> [<ffffffff8111156a>] do_sync_write+0xea/0x130
> [<ffffffff81112183>] vfs_write+0xf3/0x1f0
> [<ffffffff81112381>] sys_write+0x51/0x90
> [<ffffffff815b5926>] system_call_fastpath+0x18/0x1d
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> This is not a hard deadlock though because administrator can still
> intervene and increase the limit on the group which helps the writer to
> finish the allocation and release the lock.
>
> This patch heals the problem by forbidding OOM from page cache charges
> (namely add_ro_page_cache_locked). mem_cgroup_cache_charge_no_oom helper
> function is defined which adds GFP_MEMCG_NO_OOM to the gfp mask which
> then tells mem_cgroup_charge_common that OOM is not allowed for the
> charge. No OOM from this path, except for fixing the bug, also make some
> sense as we really do not want to cause an OOM because of a page cache
> usage.
> As a possibly visible result add_to_page_cache_lru might fail more often
> with ENOMEM but this is to be expected if the limit is set and it is
> preferable than OOM killer IMO.
>
> __GFP_NORETRY is abused for this memcg specific flag because it has been
> used to prevent from OOM already (since not-merged-yet "memcg: reclaim
> when more than one page needed"). The only difference is that the flag
> doesn't prevent from reclaim anymore which kind of makes sense because
> the global memory allocator triggers reclaim as well. The retry without
> any reclaim on __GFP_NORETRY doesn't make much sense anyway because this
> is effectively a busy loop with allowed OOM in this path.
>
> Reported-by: azurIt <azurit@pobox.sk>
> Signed-off-by: Michal Hocko <mhocko@suse.cz>
As a short term fix, I think this patch will work enough and seems simple enough.
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Reading discussion between you and Johannes, to release locks, I understand
the memcg need to return "RETRY" for a long term fix. Thinking a little,
it will be simple to return "RETRY" to all processes waited on oom kill queue
of a memcg and it can be done by a small fixes to memory.c.
Thank you.
-Kame
> ---
> include/linux/gfp.h | 3 +++
> include/linux/memcontrol.h | 12 ++++++++++++
> mm/filemap.c | 8 +++++++-
> mm/memcontrol.c | 5 +----
> 4 files changed, 23 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index 10e667f..aac9b21 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -152,6 +152,9 @@ struct vm_area_struct;
> /* 4GB DMA on some platforms */
> #define GFP_DMA32 __GFP_DMA32
>
> +/* memcg oom killer is not allowed */
> +#define GFP_MEMCG_NO_OOM __GFP_NORETRY
> +
> /* Convert GFP flags to their corresponding migrate type */
> static inline int allocflags_to_migratetype(gfp_t gfp_flags)
> {
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 095d2b4..1ad4bc6 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -65,6 +65,12 @@ extern void mem_cgroup_cancel_charge_swapin(struct mem_cgroup *memcg);
> extern int mem_cgroup_cache_charge(struct page *page, struct mm_struct *mm,
> gfp_t gfp_mask);
>
> +static inline int mem_cgroup_cache_charge_no_oom(struct page *page,
> + struct mm_struct *mm, gfp_t gfp_mask)
> +{
> + return mem_cgroup_cache_charge(page, mm, gfp_mask | GFP_MEMCG_NO_OOM);
> +}
> +
> struct lruvec *mem_cgroup_zone_lruvec(struct zone *, struct mem_cgroup *);
> struct lruvec *mem_cgroup_page_lruvec(struct page *, struct zone *);
>
> @@ -215,6 +221,12 @@ static inline int mem_cgroup_cache_charge(struct page *page,
> return 0;
> }
>
> +static inline int mem_cgroup_cache_charge_no_oom(struct page *page,
> + struct mm_struct *mm, gfp_t gfp_mask)
> +{
> + return 0;
> +}
> +
> static inline int mem_cgroup_try_charge_swapin(struct mm_struct *mm,
> struct page *page, gfp_t gfp_mask, struct mem_cgroup **memcgp)
> {
> diff --git a/mm/filemap.c b/mm/filemap.c
> index 83efee7..ef14351 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -447,7 +447,13 @@ int add_to_page_cache_locked(struct page *page, struct address_space *mapping,
> VM_BUG_ON(!PageLocked(page));
> VM_BUG_ON(PageSwapBacked(page));
>
> - error = mem_cgroup_cache_charge(page, current->mm,
> + /*
> + * Cannot trigger OOM even if gfp_mask would allow that normally
> + * because we might be called from a locked context and that
> + * could lead to deadlocks if the killed process is waiting for
> + * the same lock.
> + */
> + error = mem_cgroup_cache_charge_no_oom(page, current->mm,
> gfp_mask & GFP_RECLAIM_MASK);
> if (error)
> goto out;
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 02ee2f7..b4754ba 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -2430,9 +2430,6 @@ static int mem_cgroup_do_charge(struct mem_cgroup *memcg, gfp_t gfp_mask,
> if (!(gfp_mask & __GFP_WAIT))
> return CHARGE_WOULDBLOCK;
>
> - if (gfp_mask & __GFP_NORETRY)
> - return CHARGE_NOMEM;
> -
> ret = mem_cgroup_reclaim(mem_over_limit, gfp_mask, flags);
> if (mem_cgroup_margin(mem_over_limit) >= nr_pages)
> return CHARGE_RETRY;
> @@ -3713,7 +3710,7 @@ static int mem_cgroup_charge_common(struct page *page, struct mm_struct *mm,
> {
> struct mem_cgroup *memcg = NULL;
> unsigned int nr_pages = 1;
> - bool oom = true;
> + bool oom = !(gfp_mask | GFP_MEMCG_NO_OOM);
> int ret;
>
> if (PageTransHuge(page)) {
>
--
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>
next prev parent reply other threads:[~2012-11-27 0:06 UTC|newest]
Thread overview: 171+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20121121200207.01068046@pobox.sk>
2012-11-22 0:26 ` memory-cgroup bug Kamezawa Hiroyuki
2012-11-22 9:36 ` azurIt
2012-11-22 21:45 ` Michal Hocko
2012-11-22 15:24 ` Michal Hocko
2012-11-22 18:05 ` azurIt
2012-11-22 21:42 ` Michal Hocko
2012-11-22 22:34 ` azurIt
2012-11-23 7:40 ` Michal Hocko
2012-11-23 9:21 ` azurIt
2012-11-23 9:28 ` Michal Hocko
2012-11-23 9:44 ` azurIt
2012-11-23 10:10 ` Michal Hocko
2012-11-23 9:34 ` Glauber Costa
2012-11-23 10:04 ` Michal Hocko
2012-11-23 14:59 ` azurIt
2012-11-25 10:17 ` Michal Hocko
2012-11-25 12:39 ` azurIt
2012-11-25 13:02 ` Michal Hocko
2012-11-25 13:27 ` azurIt
2012-11-25 13:44 ` Michal Hocko
2012-11-25 0:10 ` azurIt
2012-11-25 12:05 ` Michal Hocko
2012-11-25 12:36 ` azurIt
2012-11-25 13:55 ` Michal Hocko
2012-11-26 0:38 ` azurIt
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:21 ` [PATCH for 3.2.34] " Michal Hocko
2012-11-26 21:28 ` azurIt
2012-11-30 1:45 ` azurIt
2012-11-30 2:29 ` azurIt
2012-11-30 12:45 ` Michal Hocko
2012-11-30 12:53 ` azurIt
2012-11-30 13:44 ` azurIt
2012-11-30 14:44 ` Michal Hocko
2012-11-30 15:03 ` Michal Hocko
2012-11-30 15:37 ` Michal Hocko
2012-11-30 15:08 ` azurIt
2012-11-30 15:39 ` Michal Hocko
2012-11-30 15:59 ` azurIt
2012-11-30 16:19 ` Michal Hocko
2012-11-30 16:26 ` azurIt
2012-11-30 16:53 ` Michal Hocko
2012-11-30 20:43 ` azurIt
2012-12-03 15:16 ` Michal Hocko
2012-12-05 1:36 ` azurIt
2012-12-05 14:17 ` Michal Hocko
2012-12-06 0:29 ` azurIt
2012-12-06 9:54 ` Michal Hocko
2012-12-06 10:12 ` azurIt
2012-12-06 17:06 ` Michal Hocko
2012-12-10 1:20 ` azurIt
2012-12-10 9:43 ` Michal Hocko
2012-12-10 10:18 ` azurIt
2012-12-10 15:52 ` Michal Hocko
2012-12-10 17:18 ` azurIt
2012-12-17 1:34 ` azurIt
2012-12-17 16:32 ` Michal Hocko
2012-12-17 18:23 ` azurIt
2012-12-17 19:55 ` Michal Hocko
2012-12-18 14:22 ` azurIt
2012-12-18 15:20 ` Michal Hocko
2012-12-24 13:25 ` azurIt
2012-12-28 16:22 ` Michal Hocko
2012-12-30 1:09 ` azurIt
2012-12-30 11:08 ` Michal Hocko
2013-01-25 15:07 ` azurIt
2013-01-25 16:31 ` Michal Hocko
2013-02-05 13:49 ` Michal Hocko
2013-02-05 14:49 ` azurIt
2013-02-05 16:09 ` Michal Hocko
2013-02-05 16:46 ` azurIt
2013-02-05 16:48 ` Greg Thelen
2013-02-05 17:46 ` Michal Hocko
2013-02-05 18:09 ` Greg Thelen
2013-02-05 18:59 ` Michal Hocko
2013-02-08 4:27 ` Greg Thelen
2013-02-08 16:29 ` Michal Hocko
2013-02-08 16:40 ` Michal Hocko
2013-02-06 1:17 ` azurIt
2013-02-06 14:01 ` Michal Hocko
2013-02-06 14:22 ` Michal Hocko
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-08 5:03 ` azurIt
2013-02-08 9:44 ` Michal Hocko
2013-02-08 11:02 ` azurIt
2013-02-08 12:38 ` Michal Hocko
2013-02-08 13:56 ` azurIt
2013-02-08 14:47 ` Michal Hocko
2013-02-08 15:24 ` Michal Hocko
2013-02-08 15:58 ` azurIt
2013-02-08 17:10 ` Michal Hocko
2013-02-08 21:02 ` azurIt
2013-02-10 15:03 ` Michal Hocko
2013-02-10 16:46 ` azurIt
2013-02-11 11:22 ` Michal Hocko
2013-02-22 8:23 ` azurIt
2013-02-22 12:52 ` Michal Hocko
2013-02-22 12:54 ` azurIt
2013-02-22 13:00 ` Michal Hocko
2013-06-06 16:04 ` Michal Hocko
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-17 10:21 ` azurIt
2013-06-19 13:26 ` Michal Hocko
2013-06-22 20:09 ` azurIt
2013-06-24 20:13 ` Johannes Weiner
2013-06-28 10:06 ` azurIt
2013-07-05 18:17 ` Johannes Weiner
2013-07-05 19:02 ` azurIt
2013-07-05 19:18 ` Johannes Weiner
2013-07-07 23:42 ` azurIt
2013-07-09 13:10 ` Michal Hocko
2013-07-09 13:19 ` azurIt
2013-07-09 13:54 ` Michal Hocko
2013-07-10 16:25 ` azurIt
2013-07-11 7:25 ` Michal Hocko
2013-07-13 23:26 ` azurIt
2013-07-13 23:51 ` azurIt
2013-07-15 15:41 ` Michal Hocko
2013-07-15 16:00 ` Michal Hocko
2013-07-16 15:35 ` Johannes Weiner
2013-07-16 16:09 ` Michal Hocko
2013-07-16 16:48 ` Johannes Weiner
2013-07-19 4:21 ` Johannes Weiner
2013-07-19 4:22 ` [patch 1/5] mm: invoke oom-killer from remaining unconverted page fault handlers 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:25 ` [patch 3/5] x86: finish fault error path with fatal signal Johannes Weiner
2013-07-24 20:32 ` Johannes Weiner
2013-07-25 20:29 ` KOSAKI Motohiro
2013-07-25 21:50 ` 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:26 ` [patch 5/5] mm: memcontrol: sanity check memcg OOM context unwind Johannes Weiner
2013-07-19 8:23 ` [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:08 ` Michal Hocko
2013-07-09 13:10 ` Michal Hocko
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-07 11:01 ` [PATCH for 3.2.34] memcg: do not trigger OOM from add_to_page_cache_locked Kamezawa Hiroyuki
2013-02-07 12:31 ` Michal Hocko
2013-02-08 4:16 ` Kamezawa Hiroyuki
2013-02-08 1:40 ` Kamezawa Hiroyuki
2013-02-08 16:01 ` Michal Hocko
2013-02-05 16:31 ` Michal Hocko
2012-12-24 13:38 ` azurIt
2012-12-28 16:35 ` Michal Hocko
2012-11-26 17:46 ` [PATCH -mm] " Johannes Weiner
2012-11-26 18:04 ` Michal Hocko
2012-11-26 18:24 ` Johannes Weiner
2012-11-26 19:03 ` Michal Hocko
2012-11-26 19:29 ` Johannes Weiner
2012-11-26 20:08 ` Michal Hocko
2012-11-26 20:19 ` Johannes Weiner
2012-11-26 20:46 ` azurIt
2012-11-26 20:53 ` Johannes Weiner
2012-11-26 22:06 ` Michal Hocko
2012-11-27 0:05 ` Kamezawa Hiroyuki [this message]
2012-11-27 9:54 ` Michal Hocko
2012-11-27 19:48 ` Johannes Weiner
2012-11-27 20:54 ` [PATCH -v2 " Michal Hocko
2012-11-27 20:59 ` Michal Hocko
2012-11-28 15:26 ` Johannes Weiner
2012-11-28 16:04 ` Michal Hocko
2012-11-28 16:37 ` Johannes Weiner
2012-11-28 16:46 ` Michal Hocko
2012-11-28 16:48 ` Michal Hocko
2012-11-28 18:44 ` Johannes Weiner
2012-11-28 20:20 ` Hugh Dickins
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=50B403CA.501@jp.fujitsu.com \
--to=kamezawa.hiroyu@jp.fujitsu.com \
--cc=azurit@pobox.sk \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).