From: Michal Hocko <mhocko@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>,
David Rientjes <rientjes@google.com>,
Johannes Weiner <hannes@cmpxchg.org>,
linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
Michal Hocko <mhocko@suse.com>
Subject: [PATCH 2/2] mm: warn about ALLOC_NO_WATERMARKS request failures
Date: Wed, 25 Nov 2015 11:40:54 +0100 [thread overview]
Message-ID: <1448448054-804-3-git-send-email-mhocko@kernel.org> (raw)
In-Reply-To: <1448448054-804-1-git-send-email-mhocko@kernel.org>
From: Michal Hocko <mhocko@suse.com>
ALLOC_NO_WATERMARKS requests can dive into memory reserves without any
restriction. They are used only in the case of emergency to allow
forward memory reclaim progress assuming the caller should return the
memory in a short time (e.g. {__GFP,PF}_MEMALLOC requests or OOM victim
on the way to exit or __GFP_NOFAIL requests hitting OOM). There is no
guarantee such request succeed because memory reserves might get
depleted as well. This might be either a result of a bug where memory
reserves are abused or a result of a too optimistic configuration of
memory reserves.
This patch makes sure that the administrator gets a warning when these
requests fail with a hint that min_free_kbytes might be used to increase
the amount of memory reserves. The warning might also help us check
whether the issue is caused by a buggy user or the configuration. To
prevent from flooding the logs the warning is on off but we allow it to
trigger again after min_free_kbytes was updated. Something really bad is
clearly going on if the warning hits even after multiple updates of
min_free_kbytes.
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
mm/page_alloc.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 70db11c27046..6a05d771cb08 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -240,6 +240,8 @@ compound_page_dtor * const compound_page_dtors[] = {
#endif
};
+/* warn about depleted watermarks */
+static bool warn_alloc_no_wmarks;
int min_free_kbytes = 1024;
int user_min_free_kbytes = -1;
@@ -2642,6 +2644,13 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned int order, int alloc_flags,
if (zonelist_rescan)
goto zonelist_scan;
+ /* WARN only once unless min_free_kbytes is updated */
+ if (warn_alloc_no_wmarks && (alloc_flags & ALLOC_NO_WATERMARKS)) {
+ warn_alloc_no_wmarks = 0;
+ WARN(1, "Memory reserves are depleted for order:%d, mode:0x%x."
+ " You might consider increasing min_free_kbytes\n",
+ order, gfp_mask);
+ }
return NULL;
}
@@ -6048,6 +6057,9 @@ static void __setup_per_zone_wmarks(void)
struct zone *zone;
unsigned long flags;
+ /* Warn when ALLOC_NO_WATERMARKS request fails */
+ warn_alloc_no_wmarks = 1;
+
/* Calculate total number of !ZONE_HIGHMEM pages */
for_each_zone(zone) {
if (!is_highmem(zone))
--
2.6.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>
next prev parent reply other threads:[~2015-11-25 10:41 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-25 10:40 [PATCH 0/2] GFP_NOFAIL reserves + warning about reserves depletion Michal Hocko
2015-11-25 10:40 ` [PATCH 1/2] mm, oom: Give __GFP_NOFAIL allocations access to memory reserves Michal Hocko
2015-11-25 10:51 ` David Rientjes
2015-11-25 11:18 ` Michal Hocko
2015-11-25 20:57 ` David Rientjes
2015-11-26 9:34 ` Michal Hocko
2015-11-30 22:17 ` David Rientjes
2015-12-02 15:07 ` Michal Hocko
2015-12-02 15:13 ` [PATCH v2] " Michal Hocko
2015-12-03 0:01 ` David Rientjes
2015-11-25 10:40 ` Michal Hocko [this message]
2015-11-25 10:59 ` [PATCH 2/2] mm: warn about ALLOC_NO_WATERMARKS request failures David Rientjes
2015-11-25 11:55 ` Michal Hocko
2015-11-25 21:01 ` David Rientjes
2015-11-26 9:52 ` Michal Hocko
2015-11-30 22:24 ` David Rientjes
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=1448448054-804-3-git-send-email-mhocko@kernel.org \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.com \
--cc=rientjes@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 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).