From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759781Ab0LNRjq (ORCPT ); Tue, 14 Dec 2010 12:39:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55184 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759383Ab0LNRjp (ORCPT ); Tue, 14 Dec 2010 12:39:45 -0500 Date: Tue, 14 Dec 2010 18:38:24 +0100 From: Andrea Arcangeli To: KAMEZAWA Hiroyuki Cc: linux-mm@kvack.org, Linus Torvalds , Andrew Morton , linux-kernel@vger.kernel.org, Marcelo Tosatti , Adam Litke , Avi Kivity , Hugh Dickins , Rik van Riel , Mel Gorman , 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 39 of 66] memcg huge memory Message-ID: <20101214173824.GJ5638@random.random> References: <877d2f205026b0463450.1288798094@v2.random> <20101119101938.2edf889f.kamezawa.hiroyu@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101119101938.2edf889f.kamezawa.hiroyu@jp.fujitsu.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 19, 2010 at 10:19:38AM +0900, KAMEZAWA Hiroyuki wrote: > On Wed, 03 Nov 2010 16:28:14 +0100 > Andrea Arcangeli wrote: > > @@ -402,9 +408,15 @@ static int do_huge_pmd_wp_page_fallback( > > for (i = 0; i < HPAGE_PMD_NR; i++) { > > pages[i] = alloc_page_vma(GFP_HIGHUSER_MOVABLE, > > vma, address); > > - if (unlikely(!pages[i])) { > > - while (--i >= 0) > > + if (unlikely(!pages[i] || > > + mem_cgroup_newpage_charge(pages[i], mm, > > + GFP_KERNEL))) { > > + if (pages[i]) > > put_page(pages[i]); > > + while (--i >= 0) { > > + mem_cgroup_uncharge_page(pages[i]); > > + put_page(pages[i]); > > + } > > Maybe you can use batched-uncharge here. > == > mem_cgroup_uncharge_start() > { > do loop; > } > mem_cgroup_uncharge_end(); > == > Then, many atomic ops can be reduced. Cute! diff --git a/mm/huge_memory.c b/mm/huge_memory.c --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -413,10 +413,12 @@ static int do_huge_pmd_wp_page_fallback( GFP_KERNEL))) { if (pages[i]) put_page(pages[i]); + mem_cgroup_uncharge_start(); while (--i >= 0) { mem_cgroup_uncharge_page(pages[i]); put_page(pages[i]); } + mem_cgroup_uncharge_end(); kfree(pages); ret |= VM_FAULT_OOM; goto out; > > > > kfree(pages); > > ret |= VM_FAULT_OOM; > > goto out; > > @@ -455,8 +467,10 @@ out: > > > > out_free_pages: > > spin_unlock(&mm->page_table_lock); > > - for (i = 0; i < HPAGE_PMD_NR; i++) > > + for (i = 0; i < HPAGE_PMD_NR; i++) { > > + mem_cgroup_uncharge_page(pages[i]); > > put_page(pages[i]); > > + } > > here, too. This is actually a very unlikely path handling a thread race condition, but I'll add it any way. diff --git a/mm/huge_memory.c b/mm/huge_memory.c --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -469,10 +469,12 @@ out: out_free_pages: spin_unlock(&mm->page_table_lock); + mem_cgroup_uncharge_start(); for (i = 0; i < HPAGE_PMD_NR; i++) { mem_cgroup_uncharge_page(pages[i]); put_page(pages[i]); } + mem_cgroup_uncharge_end(); kfree(pages); goto out; } > Hmm...it seems there are no codes for move_account() hugepage in series. > I think it needs some complicated work to walk page table. Agreed. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail172.messagelabs.com (mail172.messagelabs.com [216.82.254.3]) by kanga.kvack.org (Postfix) with SMTP id 58FB96B0088 for ; Tue, 14 Dec 2010 12:39:55 -0500 (EST) Date: Tue, 14 Dec 2010 18:38:24 +0100 From: Andrea Arcangeli Subject: Re: [PATCH 39 of 66] memcg huge memory Message-ID: <20101214173824.GJ5638@random.random> References: <877d2f205026b0463450.1288798094@v2.random> <20101119101938.2edf889f.kamezawa.hiroyu@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101119101938.2edf889f.kamezawa.hiroyu@jp.fujitsu.com> Sender: owner-linux-mm@kvack.org To: KAMEZAWA Hiroyuki Cc: linux-mm@kvack.org, Linus Torvalds , Andrew Morton , linux-kernel@vger.kernel.org, Marcelo Tosatti , Adam Litke , Avi Kivity , Hugh Dickins , Rik van Riel , Mel Gorman , 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 List-ID: On Fri, Nov 19, 2010 at 10:19:38AM +0900, KAMEZAWA Hiroyuki wrote: > On Wed, 03 Nov 2010 16:28:14 +0100 > Andrea Arcangeli wrote: > > @@ -402,9 +408,15 @@ static int do_huge_pmd_wp_page_fallback( > > for (i = 0; i < HPAGE_PMD_NR; i++) { > > pages[i] = alloc_page_vma(GFP_HIGHUSER_MOVABLE, > > vma, address); > > - if (unlikely(!pages[i])) { > > - while (--i >= 0) > > + if (unlikely(!pages[i] || > > + mem_cgroup_newpage_charge(pages[i], mm, > > + GFP_KERNEL))) { > > + if (pages[i]) > > put_page(pages[i]); > > + while (--i >= 0) { > > + mem_cgroup_uncharge_page(pages[i]); > > + put_page(pages[i]); > > + } > > Maybe you can use batched-uncharge here. > == > mem_cgroup_uncharge_start() > { > do loop; > } > mem_cgroup_uncharge_end(); > == > Then, many atomic ops can be reduced. Cute! diff --git a/mm/huge_memory.c b/mm/huge_memory.c --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -413,10 +413,12 @@ static int do_huge_pmd_wp_page_fallback( GFP_KERNEL))) { if (pages[i]) put_page(pages[i]); + mem_cgroup_uncharge_start(); while (--i >= 0) { mem_cgroup_uncharge_page(pages[i]); put_page(pages[i]); } + mem_cgroup_uncharge_end(); kfree(pages); ret |= VM_FAULT_OOM; goto out; > > > > kfree(pages); > > ret |= VM_FAULT_OOM; > > goto out; > > @@ -455,8 +467,10 @@ out: > > > > out_free_pages: > > spin_unlock(&mm->page_table_lock); > > - for (i = 0; i < HPAGE_PMD_NR; i++) > > + for (i = 0; i < HPAGE_PMD_NR; i++) { > > + mem_cgroup_uncharge_page(pages[i]); > > put_page(pages[i]); > > + } > > here, too. This is actually a very unlikely path handling a thread race condition, but I'll add it any way. diff --git a/mm/huge_memory.c b/mm/huge_memory.c --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -469,10 +469,12 @@ out: out_free_pages: spin_unlock(&mm->page_table_lock); + mem_cgroup_uncharge_start(); for (i = 0; i < HPAGE_PMD_NR; i++) { mem_cgroup_uncharge_page(pages[i]); put_page(pages[i]); } + mem_cgroup_uncharge_end(); kfree(pages); goto out; } > Hmm...it seems there are no codes for move_account() hugepage in series. > I think it needs some complicated work to walk page table. Agreed. -- 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