Re: [PATCH 1/2] Make page->private usable in compound pages V1

[Andrew Morton]

On Thu,  5 Apr 2007 15:36:51 -0700 (PDT)
Christoph Lameter <clameter@xxxxxxx> wrote:

> If we add a new flag so that we can distinguish between the
> first page and the tail pages then we can avoid to use page->private
> in the first page. page->private == page for the first page, so there
> is no real information in there.
> 
> Freeing up page->private makes the use of compound pages more transparent.
> They become more usable like real pages. Right now we have to be careful f.e.
> if we are going beyond PAGE_SIZE allocations in the slab on i386 because we
> can then no longer use the private field. This is one of the issues that
> cause us not to support debugging for page size slabs in SLAB.
> 
> Having page->private available for SLUB would allow more meta information
> in the page struct. I can probably avoid the 16 bit ints that I have in
> there right now.
> 
> Also if page->private is available then a compound page may be equipped
> with buffer heads. This may free up the way for filesystems to support
> larger blocks than page size.
> 
> We add PageTail as an alias of PageReclaim. Compound pages cannot
> currently be reclaimed. Because of the alias one needs to check
> PageCompound first.

So slub is using compound pages so that it can locate the head page in
higher-order pages, whereas slab uses per-object (or per-order-0-page?)
metadata for that?

I see four instances of

+	page = virt_to_page(p);
+
+	if (unlikely(PageCompound(page)))
+		page = page->first_page;

A new virt_to_head_page() is needed.


Sigh.  We're seeing rather a lot of churn to accommodate slub.  Do we
actually have any justification for all this?  If we end up deciding to
merge slub and to deprecate then remove slab, what would our reasons have
been?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/