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@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
