Re: [PATCH] Radix-tree pagecache for 2.5

Daniel Phillips (phillips@bonn-fries.net)
Wed, 30 Jan 2002 04:00:08 +0100


On January 30, 2002 12:35 am, Rik van Riel wrote:
> On Tue, 29 Jan 2002, Alan Cox wrote:
> > > We can let oracle shared memory segments use 4 MB pages,
> > > but still use the normal page cache code to look up the
> > > pages.
> >
> > That has some potential big wins beyond oracle. Some of the big number
> > crunching algorithms also benefit heavily from 4Mb pages even when you
> > try and minimise tlb misses.
>
> Note that I'm not sure whether the complexity of using
> 4 MB pages is worth it or not ... I just like the fact
> that the radix tree page cache gives us the opportunity
> to easily implement and try it.
>
> I like radix trees for making our design more flexible
> and opening doors to possible new functionality.
>
> It could even be a CONFIG option for the embedded folks,
> if we can keep the code isolated enough ;)

Making it a CONFIG option would preclude leveraging the advantages of the
radix tree that fall out from its ordered nature, so I'd vote for all or
nothing in this case.

I also have some perhaps-twisted plans for this thing, but if this patch
passes muster on its own merits - that is, in the context we're currently
using the pcache hash as opposed to new capabilities that can be leveraged -
that's the ideal situation. Hence no, or minimal, talking up other
advantages.

I'm inclined to think that the radix tree has locality advantages for UP as
well as SMP, under certain types of filesystem loads, and that it is never
worse. Well, we shall see about that soon enogh.

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