From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754925Ab1A1IET (ORCPT ); Fri, 28 Jan 2011 03:04:19 -0500 Received: from mail-iy0-f174.google.com ([209.85.210.174]:39746 "EHLO mail-iy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754039Ab1A1IER (ORCPT ); Fri, 28 Jan 2011 03:04:17 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=obje3sfvHoql/V95n3qVxEgFK7mJOMhZ+RtFtlPtB3/w5AanVZWOiH81Kp5yuVroW8 mBIWxX429CVfnYm4MiE0deRoYnloOWRGmRFuu3FEH+uSUsYzM7w+dlqpxkqZTFaNkeoT dUgd46yqC8XhQ8wXFvTG1hIQhmLKeiF0bkS8U= MIME-Version: 1.0 In-Reply-To: <20110128135839.d53422e8.kamezawa.hiroyu@jp.fujitsu.com> References: <20110128122229.6a4c74a2.kamezawa.hiroyu@jp.fujitsu.com> <20110128122449.e4bb0e5f.kamezawa.hiroyu@jp.fujitsu.com> <20110128134019.27abcfe2.nishimura@mxp.nes.nec.co.jp> <20110128135839.d53422e8.kamezawa.hiroyu@jp.fujitsu.com> Date: Fri, 28 Jan 2011 17:04:16 +0900 Message-ID: Subject: Re: [BUGFIX][PATCH 1/4] memcg: fix limit estimation at reclaim for hugepage From: Minchan Kim To: KAMEZAWA Hiroyuki Cc: Daisuke Nishimura , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "hannes@cmpxchg.org" , "balbir@linux.vnet.ibm.com" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Kame, On Fri, Jan 28, 2011 at 1:58 PM, KAMEZAWA Hiroyuki wrote: > How about this ? > == > From: KAMEZAWA Hiroyuki > > Current memory cgroup's code tends to assume page_size == PAGE_SIZE > and arrangement for THP is not enough yet. > > This is one of fixes for supporing THP. This adds > mem_cgroup_check_margin() and checks whether there are required amount of > free resource after memory reclaim. By this, THP page allocation > can know whether it really succeeded or not and avoid infinite-loop > and hangup. > > Total fixes for do_charge()/reclaim memory will follow this patch. If this patch is only related to THP, I think patch order isn't good. Before applying [2/4], huge page allocation will retry without reclaiming and loop forever by below part. @@ -1854,9 +1858,6 @@ static int __mem_cgroup_do_charge(struct } else mem_over_limit = mem_cgroup_from_res_counter(fail_res, res); - if (csize > PAGE_SIZE) /* change csize and retry */ - return CHARGE_RETRY; - if (!(gfp_mask & __GFP_WAIT)) return CHARGE_WOULDBLOCK; Am I missing something? -- Kind regards, Minchan Kim From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail143.messagelabs.com (mail143.messagelabs.com [216.82.254.35]) by kanga.kvack.org (Postfix) with ESMTP id 62D048D0039 for ; Fri, 28 Jan 2011 03:04:18 -0500 (EST) Received: by iyj17 with SMTP id 17so2420485iyj.14 for ; Fri, 28 Jan 2011 00:04:16 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20110128135839.d53422e8.kamezawa.hiroyu@jp.fujitsu.com> References: <20110128122229.6a4c74a2.kamezawa.hiroyu@jp.fujitsu.com> <20110128122449.e4bb0e5f.kamezawa.hiroyu@jp.fujitsu.com> <20110128134019.27abcfe2.nishimura@mxp.nes.nec.co.jp> <20110128135839.d53422e8.kamezawa.hiroyu@jp.fujitsu.com> Date: Fri, 28 Jan 2011 17:04:16 +0900 Message-ID: Subject: Re: [BUGFIX][PATCH 1/4] memcg: fix limit estimation at reclaim for hugepage From: Minchan Kim Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org To: KAMEZAWA Hiroyuki Cc: Daisuke Nishimura , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "hannes@cmpxchg.org" , "balbir@linux.vnet.ibm.com" List-ID: Hi Kame, On Fri, Jan 28, 2011 at 1:58 PM, KAMEZAWA Hiroyuki wrote: > How about this ? > == > From: KAMEZAWA Hiroyuki > > Current memory cgroup's code tends to assume page_size == PAGE_SIZE > and arrangement for THP is not enough yet. > > This is one of fixes for supporing THP. This adds > mem_cgroup_check_margin() and checks whether there are required amount of > free resource after memory reclaim. By this, THP page allocation > can know whether it really succeeded or not and avoid infinite-loop > and hangup. > > Total fixes for do_charge()/reclaim memory will follow this patch. If this patch is only related to THP, I think patch order isn't good. Before applying [2/4], huge page allocation will retry without reclaiming and loop forever by below part. @@ -1854,9 +1858,6 @@ static int __mem_cgroup_do_charge(struct } else mem_over_limit = mem_cgroup_from_res_counter(fail_res, res); - if (csize > PAGE_SIZE) /* change csize and retry */ - return CHARGE_RETRY; - if (!(gfp_mask & __GFP_WAIT)) return CHARGE_WOULDBLOCK; Am I missing something? -- Kind regards, Minchan Kim -- 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/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: email@kvack.org