Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758189Ab0LOASU (ORCPT ); Tue, 14 Dec 2010 19:18:20 -0500 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]:42861 "EHLO fgwmail6.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753665Ab0LOASS (ORCPT ); Tue, 14 Dec 2010 19:18:18 -0500 X-SecurityPolicyCheck-FJ: OK by FujitsuOutboundMailChecker v1.3.1 Date: Wed, 15 Dec 2010 09:12:09 +0900 From: KAMEZAWA Hiroyuki To: Andrea Arcangeli Cc: Mel Gorman , linux-mm@kvack.org, Linus Torvalds , Andrew Morton , linux-kernel@vger.kernel.org, Marcelo Tosatti , Adam Litke , Avi Kivity , Hugh Dickins , Rik van Riel , Dave Hansen , Benjamin Herrenschmidt , Ingo Molnar , Mike Travis , Christoph Lameter , Chris Wright , bpicco@redhat.com, KOSAKI Motohiro , Balbir Singh , "Michael S. Tsirkin" , Peter Zijlstra , Johannes Weiner , Daisuke Nishimura , Chris Mason , Borislav Petkov Subject: Re: [PATCH 36 of 66] memcg compound Message-Id: <20101215091209.8c757ad1.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: <20101214173817.GH5638@random.random> References: <495ffee2d60adab4d18b.1288798091@v2.random> <20101118152628.GY8135@csn.ul.ie> <20101119101041.ffe00712.kamezawa.hiroyu@jp.fujitsu.com> <20101214173817.GH5638@random.random> Organization: FUJITSU Co. LTD. X-Mailer: Sylpheed 3.0.3 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1924 Lines: 58 On Tue, 14 Dec 2010 18:38:17 +0100 Andrea Arcangeli wrote: > > > > @@ -2491,14 +2503,14 @@ __do_uncharge(struct mem_cgroup *mem, co > > > > if (batch->memcg != mem) > > > > goto direct_uncharge; > > > > /* remember freed charge and uncharge it later */ > > > > - batch->bytes += PAGE_SIZE; > > > > + batch->bytes += page_size; > > > > Hmm, isn't it simpler to avoid batched-uncharge when page_size > PAGE_SIZE ? > > As you wish, so I'm changing it like this. > > archs where the pmd is implemented purely in software might actually > be able to use page sizes smaller than 2M that may make sense to > batch, but for now if you think this is simpler I'll go for it. We > need simple. > Thank you. Hmm,..seems not very simple :( I'm sorry. Please do as you want. -Kame > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -2503,6 +2503,9 @@ __do_uncharge(struct mem_cgroup *mem, co > if (!batch->do_batch || test_thread_flag(TIF_MEMDIE)) > goto direct_uncharge; > > + if (page_size != PAGE_SIZE) > + goto direct_uncharge; > + > /* > * In typical case, batch->memcg == mem. This means we can > * merge a series of uncharges to an uncharge of res_counter. > @@ -2511,9 +2514,9 @@ __do_uncharge(struct mem_cgroup *mem, co > if (batch->memcg != mem) > goto direct_uncharge; > /* remember freed charge and uncharge it later */ > - batch->bytes += page_size; > + batch->bytes += PAGE_SIZE; > if (uncharge_memsw) > - batch->memsw_bytes += page_size; > + batch->memsw_bytes += PAGE_SIZE; > return; > direct_uncharge: > res_counter_uncharge(&mem->res, page_size); > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/