Re: [PATCH 1/3] hugetlb: Correct page count for surplus huge pages

[Adam Litke <agl@us.ibm.com>]

On Mon, 2008-02-25 at 14:26 -0800, Dave Hansen wrote:
> Mon, 2008-02-25 at 14:01 -0800, Adam Litke wrote:
> > 
> >         spin_lock(&hugetlb_lock);
> >         if (page) {
> > +               /*
> > +                * This page is now managed by the hugetlb allocator and has
> > +                * no current users -- reset its reference count.
> > +                */
> > +               set_page_count(page, 0);
> 
> So, they come out of the allocator and have a refcount of 1, and you
> want them to be consistent with the other huge pages that have a count
> of 0?

Yep all pages come out of the buddy allocator in this state.  What is
different in this case is that we are choosing not to enqueue it into
the hugetlb pool right away since it might be immediately needed by the
caller.

> I'd feel a lot better about this if you did a __put_page() then a
> atomic_read() or equivalent to double-check what's going on.  (I
> basically suggested the same thing to Jon Tollefson on the ginormous
> page stuff).  It just forces the thing to be more consistent.

I could agree to this.

> It also seems a bit goofy to me to zero the refcount here, then reset it
> to one later on in update_and_free_page().

Yeah, it is a special case -- and commented accordingly.  Do you have
any ideas how to avoid it without the wasted time of an
enqueue_huge_page()/dequeue_huge_page() cycle?

> I dunno.  It just seems like every time something in here gets touched,
> three other things break.  Makes me nervous. :(

Now c'mon, that's not fair.  I'd expect that sort of statement from the
Hillary Clinton campaign, not you Dave :)

-- 
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>