Re: [RFC] Use compound pages for higher order slab allocations.

[Christoph Lameter <clameter@engr.sgi.com>]

On Sat, 3 Dec 2005, Manfred Spraul wrote:

> Christoph Lameter wrote:
> 
> > +static inline struct page *virt_to_compound_page(const void *addr)
> > +{
> > +	struct page * page = virt_to_page(addr);
> > +
> > +	if (PageCompound(page))
> > +        	page = (struct page *)page_private(page);
> > +
> >  
> This would end up in every kmem_cache_free/kfree call. Is it really worth the
> effort, are the high order allocation a problem?

The use of compound pages allows the handling of the higher order 
allocated page as one unit in a generic slab independent way. Currently 
struct page elements have a slab specific meaning and must be 
inspected in a slab specific way to figure out where the 
higher order page starts. Having compound pages allows a generic handling
of higher order pages unifying f.e. hugepage handling with slab handling etc.

Not sure if this is worth it but it may make the handling of these pages 
easier for page migration, hotplug and bad memory relocation. Other 
endeavors that either scan struct page arrays or may start processing with 
any struct page also currently have to deal with the slab specific way of 
handling higher order pages.

> I'm against such a change without a clear proof that just using high order
> allocations is not possible.

We are doing it right now so its definitely possible.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/