From: Fengguang Wu <fengguang.wu@intel.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujtisu.com>,
Mel Gorman <mgorman@suse.de>, Minchan Kim <minchan@kernel.org>,
Rik van Riel <riel@redhat.com>, Ying Han <yinghan@google.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Greg Thelen <gthelen@google.com>, Hugh Dickins <hughd@google.com>
Subject: Re: [RFC -mm] memcg: prevent from OOM with too many dirty pages
Date: Tue, 29 May 2012 11:08:57 +0800 [thread overview]
Message-ID: <20120529030857.GA7762@localhost> (raw)
In-Reply-To: <1338219535-7874-1-git-send-email-mhocko@suse.cz>
Hi Michal,
On Mon, May 28, 2012 at 05:38:55PM +0200, Michal Hocko wrote:
> Current implementation of dirty pages throttling is not memcg aware which makes
> it easy to have LRUs full of dirty pages which might lead to memcg OOM if the
> hard limit is small and so the lists are scanned faster than pages written
> back.
>
> This patch fixes the problem by throttling the allocating process (possibly
> a writer) during the hard limit reclaim by waiting on PageReclaim pages.
> We are waiting only for PageReclaim pages because those are the pages
> that made one full round over LRU and that means that the writeback is much
> slower than scanning.
> The solution is far from being ideal - long term solution is memcg aware
> dirty throttling - but it is meant to be a band aid until we have a real
> fix.
IMHO it's still an important "band aid" -- perhaps worthwhile for
sending to Greg's stable trees. Because it fixes a really important
use case: it enables the users to put backups into a small memcg.
The users visible changes are:
the backup program get OOM killed
=>
it runs now, although being a bit slow and bumpy
Talking about the more comprehensive fix, I'm sorry for delaying this
patch for several months:
[PATCH 6/9] vmscan: dirty reclaim throttling
http://thread.gmane.org/gmane.linux.kernel.mm/74582
Now that Jan's iput() avoidance patchset has just been merged by
Linus, I'll rebase the patchset on top of his great work.
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index c978ce4..7cccd81 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -720,9 +720,20 @@ static unsigned long shrink_page_list(struct list_head *page_list,
> (PageSwapCache(page) && (sc->gfp_mask & __GFP_IO));
>
> if (PageWriteback(page)) {
> - nr_writeback++;
> - unlock_page(page);
> - goto keep;
> + /*
> + * memcg doesn't have any dirty pages throttling so we
> + * could easily OOM just because too many pages are in
> + * writeback from reclaim and there is nothing else to
> + * reclaim.
> + */
> + if (PageReclaim(page)
> + && may_enter_fs && !global_reclaim(sc))
> + wait_on_page_writeback(page);
> + else {
> + nr_writeback++;
> + unlock_page(page);
> + goto keep;
> + }
> }
>
> references = page_check_references(page, sc);
Reviewed-by: Fengguang Wu <fengguang.wu@intel.com>
This is all good for memcg. I'd suggest sending it to 3.5 and 3.4.x as well.
Thanks,
Fengguang
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Fengguang Wu <fengguang.wu@intel.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujtisu.com>,
Mel Gorman <mgorman@suse.de>, Minchan Kim <minchan@kernel.org>,
Rik van Riel <riel@redhat.com>, Ying Han <yinghan@google.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Greg Thelen <gthelen@google.com>, Hugh Dickins <hughd@google.com>
Subject: Re: [RFC -mm] memcg: prevent from OOM with too many dirty pages
Date: Tue, 29 May 2012 11:08:57 +0800 [thread overview]
Message-ID: <20120529030857.GA7762@localhost> (raw)
In-Reply-To: <1338219535-7874-1-git-send-email-mhocko@suse.cz>
Hi Michal,
On Mon, May 28, 2012 at 05:38:55PM +0200, Michal Hocko wrote:
> Current implementation of dirty pages throttling is not memcg aware which makes
> it easy to have LRUs full of dirty pages which might lead to memcg OOM if the
> hard limit is small and so the lists are scanned faster than pages written
> back.
>
> This patch fixes the problem by throttling the allocating process (possibly
> a writer) during the hard limit reclaim by waiting on PageReclaim pages.
> We are waiting only for PageReclaim pages because those are the pages
> that made one full round over LRU and that means that the writeback is much
> slower than scanning.
> The solution is far from being ideal - long term solution is memcg aware
> dirty throttling - but it is meant to be a band aid until we have a real
> fix.
IMHO it's still an important "band aid" -- perhaps worthwhile for
sending to Greg's stable trees. Because it fixes a really important
use case: it enables the users to put backups into a small memcg.
The users visible changes are:
the backup program get OOM killed
=>
it runs now, although being a bit slow and bumpy
Talking about the more comprehensive fix, I'm sorry for delaying this
patch for several months:
[PATCH 6/9] vmscan: dirty reclaim throttling
http://thread.gmane.org/gmane.linux.kernel.mm/74582
Now that Jan's iput() avoidance patchset has just been merged by
Linus, I'll rebase the patchset on top of his great work.
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index c978ce4..7cccd81 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -720,9 +720,20 @@ static unsigned long shrink_page_list(struct list_head *page_list,
> (PageSwapCache(page) && (sc->gfp_mask & __GFP_IO));
>
> if (PageWriteback(page)) {
> - nr_writeback++;
> - unlock_page(page);
> - goto keep;
> + /*
> + * memcg doesn't have any dirty pages throttling so we
> + * could easily OOM just because too many pages are in
> + * writeback from reclaim and there is nothing else to
> + * reclaim.
> + */
> + if (PageReclaim(page)
> + && may_enter_fs && !global_reclaim(sc))
> + wait_on_page_writeback(page);
> + else {
> + nr_writeback++;
> + unlock_page(page);
> + goto keep;
> + }
> }
>
> references = page_check_references(page, sc);
Reviewed-by: Fengguang Wu <fengguang.wu@intel.com>
This is all good for memcg. I'd suggest sending it to 3.5 and 3.4.x as well.
Thanks,
Fengguang
next prev parent reply other threads:[~2012-05-29 3:10 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-28 15:38 [RFC -mm] memcg: prevent from OOM with too many dirty pages Michal Hocko
2012-05-28 15:38 ` Michal Hocko
2012-05-29 3:08 ` Fengguang Wu [this message]
2012-05-29 3:08 ` Fengguang Wu
2012-05-29 7:28 ` Johannes Weiner
2012-05-29 7:28 ` Johannes Weiner
2012-05-29 8:48 ` Fengguang Wu
2012-05-29 8:48 ` Fengguang Wu
2012-05-29 9:35 ` Johannes Weiner
2012-05-29 9:35 ` Johannes Weiner
2012-05-29 10:21 ` Fengguang Wu
2012-05-29 10:21 ` Fengguang Wu
2012-05-29 13:32 ` Mel Gorman
2012-05-29 13:32 ` Mel Gorman
2012-05-29 13:51 ` Michal Hocko
2012-05-29 13:51 ` Michal Hocko
2012-05-31 9:09 ` Michal Hocko
2012-06-01 8:37 ` Michal Hocko
2012-06-01 8:37 ` Michal Hocko
2012-06-07 14:45 ` Michal Hocko
2012-06-07 14:45 ` Michal Hocko
2012-06-14 7:27 ` Johannes Weiner
2012-06-14 7:27 ` Johannes Weiner
2012-06-14 10:13 ` Michal Hocko
2012-06-14 10:13 ` Michal Hocko
2012-05-31 15:18 ` Fengguang Wu
[not found] ` <20120531153249.GD12809@tiehlicka.suse.cz>
[not found] ` <20120531154248.GA32734@localhost>
[not found] ` <20120531154859.GA20546@tiehlicka.suse.cz>
[not found] ` <20120531160129.GA439@localhost>
[not found] ` <20120531182509.GA22539@tiehlicka.suse.cz>
2012-06-01 1:33 ` Fengguang Wu
2012-06-01 1:33 ` Fengguang Wu
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=20120529030857.GA7762@localhost \
--to=fengguang.wu@intel.com \
--cc=akpm@linux-foundation.org \
--cc=gthelen@google.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=kamezawa.hiroyu@jp.fujtisu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.cz \
--cc=minchan@kernel.org \
--cc=riel@redhat.com \
--cc=yinghan@google.com \
/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.