From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758000Ab3BGCu7 (ORCPT ); Wed, 6 Feb 2013 21:50:59 -0500 Received: from e23smtp09.au.ibm.com ([202.81.31.142]:60546 "EHLO e23smtp09.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757607Ab3BGCu6 (ORCPT ); Wed, 6 Feb 2013 21:50:58 -0500 Message-ID: <1360205438.13550.11.camel@ThinkPad-T5421.cn.ibm.com> Subject: Re: [PATCH v2 3/3] mm: accelerate munlock() treatment of THP pages From: Li Zhong To: Sasha Levin Cc: Michel Lespinasse , Andrea Arcangeli , Rik van Riel , Mel Gorman , Hugh Dickins , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Date: Thu, 07 Feb 2013 10:50:38 +0800 In-Reply-To: <5112EAE8.8070503@oracle.com> References: <1359962232-20811-1-git-send-email-walken@google.com> <1359962232-20811-4-git-send-email-walken@google.com> <5112EAE8.8070503@oracle.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13020702-3568-0000-0000-0000031FBB4B Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2013-02-06 at 18:44 -0500, Sasha Levin wrote: > On 02/04/2013 02:17 AM, Michel Lespinasse wrote: > > munlock_vma_pages_range() was always incrementing addresses by PAGE_SIZE > > at a time. When munlocking THP pages (or the huge zero page), this resulted > > in taking the mm->page_table_lock 512 times in a row. > > > > We can do better by making use of the page_mask returned by follow_page_mask > > (for the huge zero page case), or the size of the page munlock_vma_page() > > operated on (for the true THP page case). > > > > Note - I am sending this as RFC only for now as I can't currently put > > my finger on what if anything prevents split_huge_page() from operating > > concurrently on the same page as munlock_vma_page(), which would mess > > up our NR_MLOCK statistics. Is this a latent bug or is there a subtle > > point I missed here ? > > > > Signed-off-by: Michel Lespinasse > > Hi Michel, > > Fuzzing with trinity inside a KVM tools guest produces a steady stream of: > > > [ 51.823275] ------------[ cut here ]------------ > [ 51.823302] kernel BUG at include/linux/page-flags.h:421! > [ 51.823307] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ 51.823307] Dumping ftrace buffer: > [ 51.823314] (ftrace buffer empty) > [ 51.823314] Modules linked in: > [ 51.823314] CPU 2 > [ 51.823314] Pid: 7116, comm: trinity Tainted: G W 3.8.0-rc6-next-20130206-sasha-00027-g3b5963c-dirty #273 > [ 51.823316] RIP: 0010:[] [] munlock_vma_page+0x12/0xf0 > [ 51.823317] RSP: 0018:ffff880009641bb8 EFLAGS: 00010282 > [ 51.823319] RAX: 011ffc0000008001 RBX: ffffea0000410040 RCX: 0000000000000000 > [ 51.823320] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffea0000410040 > [ 51.823321] RBP: ffff880009641bc8 R08: 0000000000000000 R09: 0000000000000000 > [ 51.823322] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880009633958 > [ 51.823324] R13: 0000000001252000 R14: ffffea0000410040 R15: 00000000000000ff > [ 51.823326] FS: 00007fe7a9046700(0000) GS:ffff88000ba00000(0000) knlGS:0000000000000000 > [ 51.823327] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 51.823328] CR2: 00007fc583b90fcb CR3: 0000000009bc8000 CR4: 00000000000406e0 > [ 51.823334] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 51.823338] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [ 51.823340] Process trinity (pid: 7116, threadinfo ffff880009640000, task ffff880009638000) > [ 51.823341] Stack: > [ 51.823344] 0000000000a01000 ffff880009633958 ffff880009641c08 ffffffff812429bd > [ 51.823373] ffff880009638000 000001ff09638000 ffff880009ade000 ffff880009633958 > [ 51.823373] ffff880009638810 ffff880009ade098 ffff880009641cb8 ffffffff81246d81 > [ 51.823373] Call Trace: > [ 51.823373] [] munlock_vma_pages_range+0x8d/0xf0 > [ 51.823373] [] exit_mmap+0x51/0x170 > [ 51.823373] [] ? __khugepaged_exit+0x8a/0xf0 > [ 51.823373] [] ? kmem_cache_free+0x22f/0x3b0 > [ 51.823373] [] ? __khugepaged_exit+0x8a/0xf0 > [ 51.823373] [] mmput+0x77/0xe0 > [ 51.823377] [] exit_mm+0x113/0x120 > [ 51.823381] [] ? _raw_spin_unlock_irq+0x51/0x80 > [ 51.823384] [] do_exit+0x24a/0x590 > [ 51.823387] [] do_group_exit+0x8a/0xc0 > [ 51.823390] [] get_signal_to_deliver+0x501/0x5b0 > [ 51.823394] [] do_signal+0x42/0x110 > [ 51.823399] [] ? rcu_eqs_exit_common+0x64/0x340 > [ 51.823404] [] ? trace_hardirqs_on+0xd/0x10 > [ 51.823407] [] ? trace_hardirqs_on_caller+0x128/0x160 > [ 51.823409] [] ? trace_hardirqs_on+0xd/0x10 > [ 51.823412] [] do_notify_resume+0x48/0xa0 > [ 51.823415] [] retint_signal+0x4d/0x92 > [ 51.823449] Code: 85 c0 75 0d 48 89 df e8 0d 30 fe ff 0f 1f 44 00 00 48 83 c4 08 5b 5d c3 90 55 48 89 e5 41 54 53 48 89 fb 48 > 8b 07 f6 c4 80 74 06 <0f> 0b 0f 1f 40 00 48 8b 07 48 c1 e8 0e 83 e0 01 83 f8 01 48 8b > [ 51.823449] RIP [] munlock_vma_page+0x12/0xf0 > [ 51.823450] RSP > [ 51.826846] ---[ end trace a7919e7f17c0a72a ]--- > The similar warning prevents my system from booting. And it seems to me that in munlock_vma_pages_range(), the page_mask needs be the page number returned from munlock_vma_page() minus 1. And the following fix solved my problem. Would you please have a try? Thanks, Zhong ================ diff --git a/mm/mlock.c b/mm/mlock.c index af1d115..1e3d794 100644 --- a/mm/mlock.c +++ b/mm/mlock.c @@ -255,7 +255,7 @@ void munlock_vma_pages_range(struct vm_area_struct *vma, unlock_page(page); put_page(page); } - page_increm = 1 + (~(start >> PAGE_SHIFT) & page_mask); + page_increm = 1 + (~(start >> PAGE_SHIFT) & (page_mask-1)); start += page_increm * PAGE_SIZE; cond_resched(); } From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx203.postini.com [74.125.245.203]) by kanga.kvack.org (Postfix) with SMTP id 7883F6B0005 for ; Wed, 6 Feb 2013 21:50:56 -0500 (EST) Received: from /spool/local by e23smtp04.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 7 Feb 2013 12:42:16 +1000 Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [9.190.235.152]) by d23dlp01.au.ibm.com (Postfix) with ESMTP id E99232CE8051 for ; Thu, 7 Feb 2013 13:50:49 +1100 (EST) Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r172cZxL1442302 for ; Thu, 7 Feb 2013 13:38:37 +1100 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r172omRu021266 for ; Thu, 7 Feb 2013 13:50:48 +1100 Message-ID: <1360205438.13550.11.camel@ThinkPad-T5421.cn.ibm.com> Subject: Re: [PATCH v2 3/3] mm: accelerate munlock() treatment of THP pages From: Li Zhong Date: Thu, 07 Feb 2013 10:50:38 +0800 In-Reply-To: <5112EAE8.8070503@oracle.com> References: <1359962232-20811-1-git-send-email-walken@google.com> <1359962232-20811-4-git-send-email-walken@google.com> <5112EAE8.8070503@oracle.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Sender: owner-linux-mm@kvack.org List-ID: To: Sasha Levin Cc: Michel Lespinasse , Andrea Arcangeli , Rik van Riel , Mel Gorman , Hugh Dickins , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org On Wed, 2013-02-06 at 18:44 -0500, Sasha Levin wrote: > On 02/04/2013 02:17 AM, Michel Lespinasse wrote: > > munlock_vma_pages_range() was always incrementing addresses by PAGE_SIZE > > at a time. When munlocking THP pages (or the huge zero page), this resulted > > in taking the mm->page_table_lock 512 times in a row. > > > > We can do better by making use of the page_mask returned by follow_page_mask > > (for the huge zero page case), or the size of the page munlock_vma_page() > > operated on (for the true THP page case). > > > > Note - I am sending this as RFC only for now as I can't currently put > > my finger on what if anything prevents split_huge_page() from operating > > concurrently on the same page as munlock_vma_page(), which would mess > > up our NR_MLOCK statistics. Is this a latent bug or is there a subtle > > point I missed here ? > > > > Signed-off-by: Michel Lespinasse > > Hi Michel, > > Fuzzing with trinity inside a KVM tools guest produces a steady stream of: > > > [ 51.823275] ------------[ cut here ]------------ > [ 51.823302] kernel BUG at include/linux/page-flags.h:421! > [ 51.823307] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ 51.823307] Dumping ftrace buffer: > [ 51.823314] (ftrace buffer empty) > [ 51.823314] Modules linked in: > [ 51.823314] CPU 2 > [ 51.823314] Pid: 7116, comm: trinity Tainted: G W 3.8.0-rc6-next-20130206-sasha-00027-g3b5963c-dirty #273 > [ 51.823316] RIP: 0010:[] [] munlock_vma_page+0x12/0xf0 > [ 51.823317] RSP: 0018:ffff880009641bb8 EFLAGS: 00010282 > [ 51.823319] RAX: 011ffc0000008001 RBX: ffffea0000410040 RCX: 0000000000000000 > [ 51.823320] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffea0000410040 > [ 51.823321] RBP: ffff880009641bc8 R08: 0000000000000000 R09: 0000000000000000 > [ 51.823322] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880009633958 > [ 51.823324] R13: 0000000001252000 R14: ffffea0000410040 R15: 00000000000000ff > [ 51.823326] FS: 00007fe7a9046700(0000) GS:ffff88000ba00000(0000) knlGS:0000000000000000 > [ 51.823327] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 51.823328] CR2: 00007fc583b90fcb CR3: 0000000009bc8000 CR4: 00000000000406e0 > [ 51.823334] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 51.823338] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [ 51.823340] Process trinity (pid: 7116, threadinfo ffff880009640000, task ffff880009638000) > [ 51.823341] Stack: > [ 51.823344] 0000000000a01000 ffff880009633958 ffff880009641c08 ffffffff812429bd > [ 51.823373] ffff880009638000 000001ff09638000 ffff880009ade000 ffff880009633958 > [ 51.823373] ffff880009638810 ffff880009ade098 ffff880009641cb8 ffffffff81246d81 > [ 51.823373] Call Trace: > [ 51.823373] [] munlock_vma_pages_range+0x8d/0xf0 > [ 51.823373] [] exit_mmap+0x51/0x170 > [ 51.823373] [] ? __khugepaged_exit+0x8a/0xf0 > [ 51.823373] [] ? kmem_cache_free+0x22f/0x3b0 > [ 51.823373] [] ? __khugepaged_exit+0x8a/0xf0 > [ 51.823373] [] mmput+0x77/0xe0 > [ 51.823377] [] exit_mm+0x113/0x120 > [ 51.823381] [] ? _raw_spin_unlock_irq+0x51/0x80 > [ 51.823384] [] do_exit+0x24a/0x590 > [ 51.823387] [] do_group_exit+0x8a/0xc0 > [ 51.823390] [] get_signal_to_deliver+0x501/0x5b0 > [ 51.823394] [] do_signal+0x42/0x110 > [ 51.823399] [] ? rcu_eqs_exit_common+0x64/0x340 > [ 51.823404] [] ? trace_hardirqs_on+0xd/0x10 > [ 51.823407] [] ? trace_hardirqs_on_caller+0x128/0x160 > [ 51.823409] [] ? trace_hardirqs_on+0xd/0x10 > [ 51.823412] [] do_notify_resume+0x48/0xa0 > [ 51.823415] [] retint_signal+0x4d/0x92 > [ 51.823449] Code: 85 c0 75 0d 48 89 df e8 0d 30 fe ff 0f 1f 44 00 00 48 83 c4 08 5b 5d c3 90 55 48 89 e5 41 54 53 48 89 fb 48 > 8b 07 f6 c4 80 74 06 <0f> 0b 0f 1f 40 00 48 8b 07 48 c1 e8 0e 83 e0 01 83 f8 01 48 8b > [ 51.823449] RIP [] munlock_vma_page+0x12/0xf0 > [ 51.823450] RSP > [ 51.826846] ---[ end trace a7919e7f17c0a72a ]--- > The similar warning prevents my system from booting. And it seems to me that in munlock_vma_pages_range(), the page_mask needs be the page number returned from munlock_vma_page() minus 1. And the following fix solved my problem. Would you please have a try? Thanks, Zhong ================ diff --git a/mm/mlock.c b/mm/mlock.c index af1d115..1e3d794 100644 --- a/mm/mlock.c +++ b/mm/mlock.c @@ -255,7 +255,7 @@ void munlock_vma_pages_range(struct vm_area_struct *vma, unlock_page(page); put_page(page); } - page_increm = 1 + (~(start >> PAGE_SHIFT) & page_mask); + page_increm = 1 + (~(start >> PAGE_SHIFT) & (page_mask-1)); start += page_increm * PAGE_SIZE; cond_resched(); } -- 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/ . Don't email: email@kvack.org