Re: [BK PATCH 2.5] Introduce 64-bit versions of PAGE_{CACHE_,}{MASK,ALIGN}

[Andrew Morton <akpm@zip.com.au>]

Andrea Arcangeli wrote:
> 
> On Sun, Jul 28, 2002 at 07:05:19PM -0700, Andrew Morton wrote:
> > But yes, all of this is a straight speed/space tradeoff.  Probably
> > some of it should be ifdeffed.
> 
> I would say so. recalculating page_address in cpu core with no cacheline
> access is one thing, deriving the index is a different thing.
> 
> > The cost of the tree walk doesn't worry me much - generally we
> > walk the tree with good locality of reference, so most everything is
> > in cache anyway.
> 
> well, the rbtree showedup heavily when it started growing more than a
> few steps, it has less locality of reference though.
> 
> >    Good luck setting up a testcase which does this ;)
> 
> a gigabit will trigger it in a millisecond. of course nobody tested it
> either I guess (I guess not many people tested the 800Gbyte offset
> either in the first place).

There's still the mempool.

We could perform a GFP_KERNEL replenishment of the ratnode mempool
after the page_cache_alloc(), and before taking any locks, if
that's needed.

> > Then again, Andi says that sizeof(struct page) is a problem for
> > x86-64.
> 
> not true.
> 
> > No recursion needed, no allocations needed.
> 
> the 28 bytes if they're on the stack they're like recursion, just using
> an interactive algorithm.
> 
> you're done with 28 bytes with a max 7/8 level tree, so 7*4 = 28 (4 size
> of pointer/long). On a 32bit arch the max index supported is
> 2^32, on a 64bit arch the max index supported is
> 2^(64-PAGE_CACHE_SHFIT), plus each pointer is 8 bytes. You may want to
> do the math to verify if you've enough stack to walk the tree in order,
> it's not obvious.

I make that 144 bytes of stack.

-