From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail138.messagelabs.com (mail138.messagelabs.com [216.82.249.35]) by kanga.kvack.org (Postfix) with SMTP id 25D9E6B002D for ; Tue, 1 Nov 2011 04:21:45 -0400 (EDT) Message-Id: <4EB01C8F0200001600008FAE@novprvlin0050.provo.novell.com> Date: Tue, 01 Nov 2011 02:21:35 -0600 From: "Guan Jun He" Subject: Re: [PATCH][mm/memory.c]: transparent hugepage check condition missed References: <1320049412-12642-1-git-send-email-gjhe@suse.com> <1320110288.22361.190.camel@sli10-conroe> In-Reply-To: <1320110288.22361.190.camel@sli10-conroe> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-linux-mm@kvack.org List-ID: To: Shaohua Li Cc: "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" >>> On 11/1/2011 at 09:18 AM, in message <1320110288.22361.190.camel@sli10-= conroe>, Shaohua Li wrote:=20 > On Mon, 2011-10-31 at 16:23 +0800, Guanjun He wrote: >> For the transparent hugepage module still does not support >> tmpfs and cache,the check condition should always be checked=20 >> to make sure that it only affect the anonymous maps, the=20 >> original check condition missed this, this patch is to fix this. >> Otherwise,the hugepage may affect the file-backed maps, >> then the cache for the small-size pages will be unuseful, >> and till now there is still no implementation for hugepage's cache. >>=20 >> Signed-off-by: Guanjun He >> --- >> mm/memory.c | 3 ++- >> 1 files changed, 2 insertions(+), 1 deletions(-) >>=20 >> diff --git a/mm/memory.c b/mm/memory.c >> index a56e3ba..79b85fe 100644 >> --- a/mm/memory.c >> +++ b/mm/memory.c >> @@ -3475,7 +3475,8 @@ int handle_mm_fault(struct mm_struct *mm, = struct=20 > vm_area_struct *vma, >> if (pmd_trans_huge(orig_pmd)) { >> if (flags & FAULT_FLAG_WRITE && >> !pmd_write(orig_pmd) && >> - !pmd_trans_splitting(orig_pmd)) >> + !pmd_trans_splitting(orig_pmd) && >> + !vma->vm_ops) >> return do_huge_pmd_wp_page(mm, vma, = address, >> pmd, orig_pmd); >> return 0; > so if vma->vm_ops !=3D NULL, how could the pmd_trans_huge(orig_pmd) be > true? We never enable THP if vma->vm_ops !=3D NULL. acturally, pmd_trans_huge(orig_pmd) only checks the _PAGE_PSE bits,=20 it's only a pagesize, not a flag to identity a hugepage. If I change my default pagesize to PAGE_PSE, then THP will be confused. There is already a defination: #define VM_HUGEPAGE 0x01000000 /* MADV_HUGEPAGE marked this vma = */ maybe,this can be the flag to identity a hugepage.But the comment marked = it only stands for MADV_HUGEPAGE, and it's still a hugepage.So, I suggest to add the check condition = !vma->vm_ops, or turn to=20 use VM_HUGEPAGE as the flag. or adjust the logic to: (transparent_hugepage_enabled() use the VM_HUGEPAGE flag) if(transparent_hugepage_enabled(vma)){ if (pmd_none(*pmd){ ... } else { ... } } the original logic is: if (pmd_none(*pmd) && transparent_hugepage_enabled(vma))=20 { ... } else { ... } -- 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 internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org