From: Glauber Costa <glommer@parallels.com>
To: <linux-kernel@vger.kernel.org>
Cc: <linux-mm@kvack.org>, Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>,
Suleiman Souhlal <suleiman@google.com>, Tejun Heo <tj@kernel.org>,
<cgroups@vger.kernel.org>, <kamezawa.hiroyu@jp.fujitsu.com>,
Michal Hocko <mhocko@suse.cz>,
Johannes Weiner <hannes@cmpxchg.org>,
Greg Thelen <gthelen@google.com>, <devel@openvz.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Glauber Costa <glommer@parallels.com>
Subject: [PATCH v4 02/14] memcg: Reclaim when more than one page needed.
Date: Mon, 8 Oct 2012 14:06:08 +0400 [thread overview]
Message-ID: <1349690780-15988-3-git-send-email-glommer@parallels.com> (raw)
In-Reply-To: <1349690780-15988-1-git-send-email-glommer@parallels.com>
From: Suleiman Souhlal <ssouhlal@FreeBSD.org>
mem_cgroup_do_charge() was written before kmem accounting, and expects
three cases: being called for 1 page, being called for a stock of 32
pages, or being called for a hugepage. If we call for 2 or 3 pages (and
both the stack and several slabs used in process creation are such, at
least with the debug options I had), it assumed it's being called for
stock and just retried without reclaiming.
Fix that by passing down a minsize argument in addition to the csize.
And what to do about that (csize == PAGE_SIZE && ret) retry? If it's
needed at all (and presumably is since it's there, perhaps to handle
races), then it should be extended to more than PAGE_SIZE, yet how far?
And should there be a retry count limit, of what? For now retry up to
COSTLY_ORDER (as page_alloc.c does) and make sure not to do it if
__GFP_NORETRY.
[v4: fixed nr pages calculation pointed out by Christoph Lameter ]
Signed-off-by: Suleiman Souhlal <suleiman@google.com>
Signed-off-by: Glauber Costa <glommer@parallels.com>
Reviewed-by: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Acked-by: Michal Hocko <mhocko@suse.cz>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
---
mm/memcontrol.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 47cb019..7a9652a 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2226,7 +2226,8 @@ enum {
};
static int mem_cgroup_do_charge(struct mem_cgroup *memcg, gfp_t gfp_mask,
- unsigned int nr_pages, bool oom_check)
+ unsigned int nr_pages, unsigned int min_pages,
+ bool oom_check)
{
unsigned long csize = nr_pages * PAGE_SIZE;
struct mem_cgroup *mem_over_limit;
@@ -2249,18 +2250,18 @@ static int mem_cgroup_do_charge(struct mem_cgroup *memcg, gfp_t gfp_mask,
} else
mem_over_limit = mem_cgroup_from_res_counter(fail_res, res);
/*
- * nr_pages can be either a huge page (HPAGE_PMD_NR), a batch
- * of regular pages (CHARGE_BATCH), or a single regular page (1).
- *
* Never reclaim on behalf of optional batching, retry with a
* single page instead.
*/
- if (nr_pages == CHARGE_BATCH)
+ if (nr_pages > min_pages)
return CHARGE_RETRY;
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;
@@ -2273,7 +2274,7 @@ static int mem_cgroup_do_charge(struct mem_cgroup *memcg, gfp_t gfp_mask,
* unlikely to succeed so close to the limit, and we fall back
* to regular pages anyway in case of failure.
*/
- if (nr_pages == 1 && ret)
+ if (nr_pages <= (1 << PAGE_ALLOC_COSTLY_ORDER) && ret)
return CHARGE_RETRY;
/*
@@ -2408,7 +2409,8 @@ again:
nr_oom_retries = MEM_CGROUP_RECLAIM_RETRIES;
}
- ret = mem_cgroup_do_charge(memcg, gfp_mask, batch, oom_check);
+ ret = mem_cgroup_do_charge(memcg, gfp_mask, batch, nr_pages,
+ oom_check);
switch (ret) {
case CHARGE_OK:
break;
--
1.7.11.4
next prev parent reply other threads:[~2012-10-08 10:10 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-08 10:06 [PATCH v4 00/14] kmem controller for memcg Glauber Costa
2012-10-08 10:06 ` [PATCH v4 01/14] memcg: Make it possible to use the stock for more than one page Glauber Costa
2012-10-08 10:06 ` Glauber Costa [this message]
2012-10-16 3:22 ` [PATCH v4 02/14] memcg: Reclaim when more than one page needed Kamezawa Hiroyuki
2012-10-08 10:06 ` [PATCH v4 03/14] memcg: change defines to an enum Glauber Costa
2012-10-08 10:06 ` [PATCH v4 04/14] kmem accounting basic infrastructure Glauber Costa
2012-10-11 10:11 ` Michal Hocko
2012-10-11 12:53 ` Michal Hocko
2012-10-11 13:38 ` Michal Hocko
2012-10-12 7:36 ` Glauber Costa
2012-10-12 8:27 ` Michal Hocko
2012-10-08 10:06 ` [PATCH v4 05/14] Add a __GFP_KMEMCG flag Glauber Costa
2012-10-09 15:04 ` Michal Hocko
2012-10-08 10:06 ` [PATCH v4 06/14] memcg: kmem controller infrastructure Glauber Costa
2012-10-11 12:42 ` Michal Hocko
2012-10-11 12:56 ` Michal Hocko
2012-10-12 7:45 ` Glauber Costa
2012-10-12 8:39 ` Michal Hocko
2012-10-12 8:44 ` Glauber Costa
2012-10-12 8:57 ` Michal Hocko
2012-10-12 9:13 ` Glauber Costa
2012-10-12 9:47 ` Michal Hocko
2012-10-16 8:00 ` Kamezawa Hiroyuki
2012-10-08 10:06 ` [PATCH v4 07/14] mm: Allocate kernel pages to the right memcg Glauber Costa
2012-10-08 10:06 ` [PATCH v4 08/14] res_counter: return amount of charges after res_counter_uncharge Glauber Costa
2012-10-09 15:08 ` Michal Hocko
2012-10-09 15:14 ` Glauber Costa
2012-10-09 15:35 ` Michal Hocko
2012-10-10 9:03 ` Glauber Costa
2012-10-10 11:24 ` Michal Hocko
2012-10-10 11:25 ` Michal Hocko
2012-10-16 8:20 ` Kamezawa Hiroyuki
2012-10-08 10:06 ` [PATCH v4 09/14] memcg: kmem accounting lifecycle management Glauber Costa
2012-10-11 13:11 ` Michal Hocko
2012-10-12 7:47 ` Glauber Costa
2012-10-12 8:41 ` Michal Hocko
2012-10-16 8:41 ` Kamezawa Hiroyuki
2012-10-08 10:06 ` [PATCH v4 10/14] memcg: use static branches when code not in use Glauber Costa
2012-10-11 13:40 ` Michal Hocko
2012-10-12 7:47 ` Glauber Costa
2012-10-16 8:48 ` Kamezawa Hiroyuki
2012-10-08 10:06 ` [PATCH v4 11/14] memcg: allow a memcg with kmem charges to be destructed Glauber Costa
2012-10-08 10:06 ` [PATCH v4 12/14] execute the whole memcg freeing in free_worker Glauber Costa
2012-10-11 14:21 ` Michal Hocko
2012-10-08 10:06 ` [PATCH v4 13/14] protect architectures where THREAD_SIZE >= PAGE_SIZE against fork bombs Glauber Costa
2012-10-08 10:06 ` [PATCH v4 14/14] Add documentation about the kmem controller Glauber Costa
2012-10-11 14:35 ` Michal Hocko
2012-10-12 7:53 ` Glauber Costa
2012-10-12 8:44 ` Michal Hocko
2012-10-17 7:29 ` Kamezawa Hiroyuki
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=1349690780-15988-3-git-send-email-glommer@parallels.com \
--to=glommer@parallels.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=devel@openvz.org \
--cc=fweisbec@gmail.com \
--cc=gthelen@google.com \
--cc=hannes@cmpxchg.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.cz \
--cc=suleiman@google.com \
--cc=tj@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®