Thread (12 messages) 12 messages, 5 authors, 2011-08-24

Re: [patch 0/3] A few patches for dcache

From: Dave Chinner <david@fromorbit.com>
Date: 2011-07-29 03:25:08

On Thu, Jul 28, 2011 at 05:12:19PM +0400, Cyrill Gorcunov wrote:
There were a thread at http://lwn.net/Articles/441164/ and while the rest of
dcache rework is still under review and discussion, the three patches might be
considered independantly.

Please review, comments are *highly* appreciated!

I've tested them locally with dbench (maybe something
else I should try?) to be sure all works as expected
but better to have them reviewed since tests do not
always reveal potential problems.

The idea of series is to remove global rename_lock and
prepare the ground for future factoring out of the
shrinker code.
The VFS shrinker code is now already called on a per-sb basis. Each
sb has it's own shrinker context that deals with dentries, inodes
and anything a filesystem wants to have shrunk in the call. That
solves the original issue I had with your "limit the dentry cache
size" patch series in that it didn't shrink or limit the other VFS
caches that were the ones that were really consuming all your
memory...

If you want to limit the size of the VFS caches on a specific
superblock, then I'm pretty sure all we need to do now is add a
method to call the per-sb shrinker when over a threshold rather than
only calling them when there is memory pressure (e.g. via a
workqueue).

Right now the only thing that will serialise this is the fact that
the dcache_lru_lock is still global. I dropped the patch to make it
per-sb because it was causing memory corruptions and crashes.  I'm
starting to test that patch again now that the dcache gurus seems to
have fixed a bunch of nasty problems that could have been causing
this...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help