Introduce a place holder page for the pagecache.

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

-
To unsubscribe from this list: send the line
"unsubscribe linux-fsdevel" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html