Re: [RFC PATCH 1/3] Introduce a place holder page for the pagecache.

[Chris Mason <chris.mason@oracle.com>]

On Fri, Nov 03, 2006 at 12:42:57PM +0530, Suparna Bhattacharya wrote:
> > 
> > My original code was fairly dumb and didn't use gang lookups.  It also
> > dropped the radix tree lock after every insert/delete.  The code posted
> > here is about 2x as fast (or 1/2 the regression, depending on how you
> > look at it).   For smaller read ios, the performance hit is about zero.
> > The cost of radix tree insertion is offset by less mutex and semaphore
> > locking.
> 
> OK, so you think the main overheads had to do with radix-tree locking,
> rather than with the additional node insertions ?

It depends on the machine I suppose.  If you have a lot of cpus trying
to work concurrently on the same file, bouncing the lock between them
(especially on numa) may be the most expensive part.  Hopefully we can
talk the XFS guys into some benchmarking, since they have a bunch of
numbers for comparison already.

But there are other costs, including slab churn as we allocate/free
radix nodes etc etc.  I think (well, hope) that on most hardware this is
a very small cost in comparison with the actual IO.

[ ... ]
> > Yes, my goal was to get the code fast enough for most machines, so that
> > we could test the result and see what impact it would have on the rest
> > of the page cache.  From here we can decide if additional radix tuning
> > is a good idea, or if we just want to stick with the mutex/semaphore
> > combo in use now.
> 
> Yup, that makes sense.
> 
> The complexity in find_and_insert_placeholder_pages does worry me though,
> wouldn't want to end up debugging tricky problems in that code after all
> this. Do you have any ideas on that ?

If we push bulk insertion down into the radix code,
find_and_insert_placeholders will become less complex.  We could even
preallocate a node that is already filled with place holders and pop
that into multiple spots in the radix tree.

-chris