From: "'David Gibson'" <david@gibson.dropbear.id.au>
To: Hugh Dickins <hugh@veritas.com>
Cc: Andrew Morton <akpm@osdl.org>,
"Chen, Kenneth W" <kenneth.w.chen@intel.com>,
William Irwin <wli@holomorphy.com>,
linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: hugepage: Fix hugepage logic in free_pgtables() harder
Date: Fri, 03 Mar 2006 05:26:02 +0000 [thread overview]
Message-ID: <20060303052602.GL23766@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.61.0603030508470.5446@goblin.wat.veritas.com>
On Fri, Mar 03, 2006 at 05:18:51AM +0000, Hugh Dickins wrote:
> On Fri, 3 Mar 2006, 'David Gibson' wrote:
>
> > 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.
>
> I agree with your patch, but not with your comment: it's just a fix
> to your earlier patch, there's no such off-by-one in the mainline
> free_pgtables. Probably you were misled by my use of "vma->vm_mm"
> rather than "next->vm_mm", equal but admittedly confusing, when
> looking at the "next" vma.
Ah, yes, indeed. The bug's all my fault, but it's still a bug.
--
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: Hugh Dickins <hugh@veritas.com>
Cc: Andrew Morton <akpm@osdl.org>,
"Chen, Kenneth W" <kenneth.w.chen@intel.com>,
William Irwin <wli@holomorphy.com>,
linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: hugepage: Fix hugepage logic in free_pgtables() harder
Date: Fri, 3 Mar 2006 16:26:02 +1100 [thread overview]
Message-ID: <20060303052602.GL23766@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.61.0603030508470.5446@goblin.wat.veritas.com>
On Fri, Mar 03, 2006 at 05:18:51AM +0000, Hugh Dickins wrote:
> On Fri, 3 Mar 2006, 'David Gibson' wrote:
>
> > 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.
>
> I agree with your patch, but not with your comment: it's just a fix
> to your earlier patch, there's no such off-by-one in the mainline
> free_pgtables. Probably you were misled by my use of "vma->vm_mm"
> rather than "next->vm_mm", equal but admittedly confusing, when
> looking at the "next" vma.
Ah, yes, indeed. The bug's all my fault, but it's still a bug.
--
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 5:26 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 ` hugepage: Fix hugepage logic in free_pgtables() harder 'David Gibson'
2006-03-03 1:04 ` 'David Gibson'
2006-03-03 5:18 ` Hugh Dickins
2006-03-03 5:18 ` Hugh Dickins
2006-03-03 5:26 ` 'David Gibson' [this message]
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=20060303052602.GL23766@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.