Re: [PATCH 01 of 28] compound_lock

[Andrea Arcangeli <aarcange@redhat.com>]

On Thu, Dec 17, 2009 at 01:46:50PM -0600, Christoph Lameter wrote:
> On Thu, 17 Dec 2009, Andrea Arcangeli wrote:
> 
> >  	if (unlikely(PageTail(page)))
> > diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> > --- a/include/linux/page-flags.h
> > +++ b/include/linux/page-flags.h
> > @@ -108,6 +108,7 @@ enum pageflags {
> >  #ifdef CONFIG_MEMORY_FAILURE
> >  	PG_hwpoison,		/* hardware poisoned page. Don't touch */
> >  #endif
> > +	PG_compound_lock,
> >  	__NR_PAGEFLAGS,
> 
> Eats up a rare page bit.
> 
> #ifdef CONFIG_TRANSP_HUGE?

It can't go under #ifdef unless I also put under #ifdef the whole
refcounting changes on the compound pages of patch 2/28. Let me know
if this is what you're asking: it would be very feasible to not have
the PG_compound_lock logic in the compound get_page/put_page when
CONFIG_TRANSPARENT_HUGEPAGE=n. I just thought it's not worth it
because the only slowdown introduced in get_page/put_page by 2/28 for
hugetlbfs happens on O_DIRECT completion handlers. The reason
hugetlbfs can implement a backwards compatible get_page/put_page
without the need of PG_compound_lock and without the need of
refcounting how many pins there are on each tail page, is that the
hugepage managed by hugetlbfs can't be splitted and swapped out. So I
can optimize away that PG_compound_lock with
CONFIG_TRANSPARENT_HUGEPAGE=n if you want.

--
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>