Re: [patch] hugepage allocator cleanup

Nick Piggin
2006-01-26T14:19:55Z

On Wed, Jan 25, 2006 at 07:04:24PM -0800, William Lee Irwin III wrote:
> On Wed, Jan 25, 2006 at 08:32:43AM -0800, William Lee Irwin III wrote:
> >> Just yanking the page refcount affairs out of update_and_free_page()
> >> should suffice. Could I get things trimmed down to that?
> >>
>
> On Wed, Jan 25, 2006 at 05:52:08PM +0100, Nick Piggin wrote:
> > I could remove the first set_page_count, and make the second conditional
> > on the page having a zero refcount... for a 3-liner. But that's kind of
> > ugly (if less intrusive), and it is adds seemingly nonsense code if one
> > doesn't have the context of my out-of-tree patches.
> > Hmm... it's obviously not 2.6.16 material so there is no rush to think
> > it over. It is even simple enough that I don't mind carrying with my
> > patchset indefinitely.
>
> After I thought about it, alloc_fresh_huge_page() does enqueue pages
> with refcounts of 1, where free_huge_page() (called from the freeing
> hook in page[1].mapping) enqueues pages with refcounts of 0, so it

Yep.

> would actually make sense (and possibly prevent leaks) to take the
> whole patch as-is.
>
>

Yeah, you could add a bad_page-like check to verify the refcount
hasn't been mucked with... and of course the regular allocator can
now verify refcounts are alright when update_and_free_page returns
them.