Re: [patch 2/14] mm: pte prefetch

[Nick Piggin <nickpiggin@yahoo.com.au>]

Arjan van de Ven wrote:
> On Sun, 2005-11-06 at 19:20 +1100, Nick Piggin wrote:
>
> > 2/14
> >
> > plain text document attachment (mm-pte-prefetch.patch)
> > Prefetch ptes a line ahead. Worth 25% on ia64 when doing big forks.
> >
> > Index: linux-2.6/include/asm-generic/pgtable.h
> > ===================================================================
> > --- linux-2.6.orig/include/asm-generic/pgtable.h
> > +++ linux-2.6/include/asm-generic/pgtable.h
> > @@ -196,6 +196,33 @@ static inline void ptep_set_wrprotect(st
> > })
> > #endif
> >
> > +#ifndef __HAVE_ARCH_PTE_PREFETCH
> > +#define PTES_PER_LINE (L1_CACHE_BYTES / sizeof(pte_t))
> > +#define PTE_LINE_MASK (~(PTES_PER_LINE - 1))
> > +#define ADDR_PER_LINE (PTES_PER_LINE << PAGE_SHIFT)
> > +#define ADDR_LINE_MASK (~(ADDR_PER_LINE - 1))
> > +
> > +#define pte_prefetch(pte, addr, end)					\
> > +({									\
> > +	unsigned long __nextline = ((addr) + ADDR_PER_LINE) & ADDR_LINE_MASK; \
> > +	if (__nextline < (end))						\
> > +		prefetch(pte + PTES_PER_LINE);				\
> > +})
> > +
>
>
> are you sure this is right? at least on pc's having a branch predictor
> miss is very expensive and might well be more expensive than the gain
> you get from a prefetch

Yeah, not 100% sure about this one, which is why it has been sitting
around for so long.

It gives about 25% on contrived fork workload on an ia64 system, which
is probably about its best case workload+architecture. I haven't found
any notable regressions but it definitely isn't going to be any faster
when the page tables are in cache.

So long as I haven't found a real-world workload that is improved with
the patch, I won't be trynig to get it merged.

--
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 
-
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/