[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FEADA55.4060409@parallels.com>
Date: Wed, 27 Jun 2012 14:03:01 +0400
From: Glauber Costa <glommer@...allels.com>
To: David Rientjes <rientjes@...gle.com>
CC: <cgroups@...r.kernel.org>, <linux-mm@...ck.org>,
Andrew Morton <akpm@...ux-foundation.org>,
<linux-kernel@...r.kernel.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Pekka Enberg <penberg@...nel.org>,
Michal Hocko <mhocko@...e.cz>,
Johannes Weiner <hannes@...xchg.org>,
Christoph Lameter <cl@...ux.com>, <devel@...nvz.org>,
<kamezawa.hiroyu@...fujitsu.com>, Tejun Heo <tj@...nel.org>,
Suleiman Souhlal <suleiman@...gle.com>
Subject: Re: [PATCH 02/11] memcg: Reclaim when more than one page needed.
On 06/26/2012 08:09 AM, David Rientjes wrote:
> @@ -2206,7 +2214,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 <= NR_PAGES_TO_RETRY && ret)
>> return CHARGE_RETRY;
Changed to costly order.
One more thing. The original version of this patch included
a cond_resched() here, that was also removed. From my re-reading
of the code in page_alloc.c and vmscan.c now, I tend to think
this is indeed not needed, since any cond_resched()s that might
be needed to ensure the safety of the code will be properly
inserted by the reclaim code itself, so there is no need for us
to include any when we signal that a retry is needed.
Do you/others agree?
--
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