From: "'David Gibson'" <david@gibson.dropbear.id.au>
To: Andrew Morton <akpm@osdl.org>
Cc: Hugh Dickins <hugh@veritas.com>,
"Chen, Kenneth W" <kenneth.w.chen@intel.com>,
William Irwin <wli@holomorphy.com>,
linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: hugepage: Fix hugepage logic in free_pgtables() harder
Date: Fri, 03 Mar 2006 01:04:08 +0000 [thread overview]
Message-ID: <20060303010408.GG23766@localhost.localdomain> (raw)
In-Reply-To: <20060302045201.GA6627@localhost.localdomain>
Sigh. Turns out the hugepage logic in free_pgtables() was doubly
broken. The loop coalescing multiple normal page VMAs into one call
to free_pgd_range() had an off by one error, which could mean it would
coalesce one hugepage VMA into the same bundle (checking 'vma' not
'next' in the loop). I transferred this bug into the new
is_vm_hugetlb_page() based version. Here's the fix.
This one didn't bite on powerpc previously for the same reason the
is_hugepage_only_range() problem didn't: powerpc's
hugetlb_free_pgd_range() is identical to free_pgd_range(). It didn't
bite on ia64 because the hugepage region is distant enough from any
other region that the separated PMD_SIZE distance test would always
prevent coalescing the two together.
No libhugetlbfs testsuite regressions (ppc64, POWER5).
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Index: working-2.6/mm/memory.c
=================================--- working-2.6.orig/mm/memory.c 2006-03-03 11:39:33.000000000 +1100
+++ working-2.6/mm/memory.c 2006-03-03 11:39:50.000000000 +1100
@@ -285,7 +285,7 @@ void free_pgtables(struct mmu_gather **t
* Optimization: gather nearby vmas into one call down
*/
while (next && next->vm_start <= vma->vm_end + PMD_SIZE
- && !is_vm_hugetlb_page(vma)) {
+ && !is_vm_hugetlb_page(next)) {
vma = next;
next = vma->vm_next;
anon_vma_unlink(vma);
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
WARNING: multiple messages have this Message-ID (diff)
From: "'David Gibson'" <david@gibson.dropbear.id.au>
To: Andrew Morton <akpm@osdl.org>
Cc: Hugh Dickins <hugh@veritas.com>,
"Chen, Kenneth W" <kenneth.w.chen@intel.com>,
William Irwin <wli@holomorphy.com>,
linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: hugepage: Fix hugepage logic in free_pgtables() harder
Date: Fri, 3 Mar 2006 12:04:08 +1100 [thread overview]
Message-ID: <20060303010408.GG23766@localhost.localdomain> (raw)
Sigh. Turns out the hugepage logic in free_pgtables() was doubly
broken. The loop coalescing multiple normal page VMAs into one call
to free_pgd_range() had an off by one error, which could mean it would
coalesce one hugepage VMA into the same bundle (checking 'vma' not
'next' in the loop). I transferred this bug into the new
is_vm_hugetlb_page() based version. Here's the fix.
This one didn't bite on powerpc previously for the same reason the
is_hugepage_only_range() problem didn't: powerpc's
hugetlb_free_pgd_range() is identical to free_pgd_range(). It didn't
bite on ia64 because the hugepage region is distant enough from any
other region that the separated PMD_SIZE distance test would always
prevent coalescing the two together.
No libhugetlbfs testsuite regressions (ppc64, POWER5).
Signed-off-by: David Gibson <dwg@au1.ibm.com>
Index: working-2.6/mm/memory.c
===================================================================
--- working-2.6.orig/mm/memory.c 2006-03-03 11:39:33.000000000 +1100
+++ working-2.6/mm/memory.c 2006-03-03 11:39:50.000000000 +1100
@@ -285,7 +285,7 @@ void free_pgtables(struct mmu_gather **t
* Optimization: gather nearby vmas into one call down
*/
while (next && next->vm_start <= vma->vm_end + PMD_SIZE
- && !is_vm_hugetlb_page(vma)) {
+ && !is_vm_hugetlb_page(next)) {
vma = next;
next = vma->vm_next;
anon_vma_unlink(vma);
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
next prev parent reply other threads:[~2006-03-03 1:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-02 4:52 hugepage: Fix hugepage logic in free_pgtables() 'David Gibson'
2006-03-02 4:52 ` 'David Gibson'
2006-03-02 18:53 ` Hugh Dickins
2006-03-02 18:53 ` Hugh Dickins
2006-03-02 19:42 ` Chen, Kenneth W
2006-03-02 19:42 ` Chen, Kenneth W
2006-03-02 20:27 ` Hugh Dickins
2006-03-02 20:27 ` Hugh Dickins
2006-03-02 23:14 ` 'David Gibson'
2006-03-02 23:14 ` 'David Gibson'
2006-03-02 21:29 ` Chen, Kenneth W
2006-03-02 21:29 ` Chen, Kenneth W
2006-03-02 23:00 ` 'David Gibson'
2006-03-02 23:00 ` 'David Gibson'
2006-03-03 1:04 ` 'David Gibson' [this message]
2006-03-03 1:04 ` hugepage: Fix hugepage logic in free_pgtables() harder 'David Gibson'
2006-03-03 5:18 ` Hugh Dickins
2006-03-03 5:18 ` Hugh Dickins
2006-03-03 5:26 ` 'David Gibson'
2006-03-03 5:26 ` 'David Gibson'
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060303010408.GG23766@localhost.localdomain \
--to=david@gibson.dropbear.id.au \
--cc=akpm@osdl.org \
--cc=hugh@veritas.com \
--cc=kenneth.w.chen@intel.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=wli@holomorphy.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.