[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140507144339.GI9489@dhcp22.suse.cz>
Date: Wed, 7 May 2014 16:43:39 +0200
From: Michal Hocko <mhocko@...e.cz>
To: Johannes Weiner <hannes@...xchg.org>
Cc: linux-mm@...ck.org, Hugh Dickins <hughd@...gle.com>,
Tejun Heo <tj@...nel.org>, cgroups@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [patch 3/9] mm: memcontrol: retry reclaim for oom-disabled and
__GFP_NOFAIL charges
On Wed 30-04-14 16:25:37, Johannes Weiner wrote:
> There is no reason why oom-disabled and __GFP_NOFAIL charges should
> try to reclaim only once when every other charge tries several times
> before giving up. Make them all retry the same number of times.
I guess the idea whas that oom disabled (THP) allocation can fallback to
a smaller allocation. I would suspect this would increase latency for
THP page faults.
__GFP_NOFAIL is a different story and it can be retried.
> Signed-off-by: Johannes Weiner <hannes@...xchg.org>
> ---
> mm/memcontrol.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 6ce59146fec7..c431a30280ac 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -2589,7 +2589,7 @@ static int mem_cgroup_try_charge(struct mem_cgroup *memcg,
> bool oom)
> {
> unsigned int batch = max(CHARGE_BATCH, nr_pages);
> - int nr_oom_retries = MEM_CGROUP_RECLAIM_RETRIES;
> + int nr_retries = MEM_CGROUP_RECLAIM_RETRIES;
> struct mem_cgroup *mem_over_limit;
> struct res_counter *fail_res;
> unsigned long nr_reclaimed;
> @@ -2660,6 +2660,9 @@ retry:
> if (mem_cgroup_wait_acct_move(mem_over_limit))
> goto retry;
>
> + if (nr_retries--)
> + goto retry;
> +
> if (gfp_mask & __GFP_NOFAIL)
> goto bypass;
>
> @@ -2669,9 +2672,6 @@ retry:
> if (!oom)
> goto nomem;
>
> - if (nr_oom_retries--)
> - goto retry;
> -
> mem_cgroup_oom(mem_over_limit, gfp_mask, get_order(batch));
> nomem:
> if (!(gfp_mask & __GFP_NOFAIL))
> --
> 1.9.2
>
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists