Re: [PATCH 2/2] Optimize compound_head() by avoiding a shared pageflag

[Christoph Lameter]

On Fri, 6 Apr 2007, Andrew Morton wrote:

> Did you investigate
> 
> static inline int page_tail(struct page *page)
> {
> 	return ((page->flags & (PG_compound|PG_tail)) == (PG_compound|PG_tail));
> }

The usual test_bit that we are using there uses a volatile reference 
so these wont be combined if I check them separately.

A working example of the above would be much uglier:

static inline int page_tail(struct page *page)
{
 	return ((page->flags & ((1L << PG_compound)|(1L << PG_tail))) == 
((1L << PG_compound)|(1L << PG_tail)));
}

May be this can be cleaned up somehow.

> 
> and
> 
> static inline int page_tail(struct page *page)
> {
> 	return unlikely(PageCompound(page)) && unlikely(PageTail(page));
> }

Two volatile references in the bit opes that the compiler cannot combine. 
Wont work unless we clean up the bitops first. This means we still have 
two branches in the code. Maybe I can make the first one work.

> In the latter case we _should_ have a not-taken branch to not-inline code. 
> If the compiler doesn't do that, we can make the PageTail() test an
> out-of-line function.  Or make the whole thing an uninlined function.

Still two branches which cannot be optimized in the same way as the single 
on on IA64 as shown by the asm that I included.
 
> More work needed, please.  I don't expect that a not-taken branch to
> not-inline code is worth a new page flag.  Especially as it does not
> actually reduce the number of branch decisions in the common case.

A new page flag does reduce the number of branches. On several platforms
it eliminates the branch completely since a single instruction can be
conditionally skipped.
 
> (I'm assuming in all of this that !PageCompound() is the very common case
> with slub.  If that is not true, we need to talk).

Yes, it is common for slabs to only have a single page.

The most promising avenue seems to be the simultaneous check for two bits.

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