On Mon, May 20, 2013 at 8:20 AM, Bob Peterson <rpeterso@xxxxxxxxxx> wrote: > > ----- Original Message ----- > | Hello, > | > | We have a bunch of servers that create a lot of temp files, or check > | for the existence of non-existent files. Every such operation creates > | a dentry object and soon most of the free memory is consumed for > | 'negative' dentry entries. This behavior was observed on both CentOS > | kernel v.2.6.32-358 and Amazon Linux kernel v.3.4.43-4. > | > | There are also some processes running that occasionally allocate large > | chunks of memory, and when this happens the kernel clears out a bunch > | of stale dentry caches. This clearing takes some time. kswapd kicks > | in, and allocations and bzero() of 4GB that normally takes <1s, takes > | 20s or more. > | > | Because the memory needs are non-continuous but negative dentry > | generation is fairly continuous, vfs_cache_pressure doesn't help much. > | > | The thought I had was to have a sysctl that limits the number of > | dentries per super-block (sb-max-dentry). Everytime a new dentry is > | allocated in d_alloc(), check if dentry_stat.nr_dentry exceeds (number > | of super blocks * sb-max-dentry). If yes, queue up an asynchronous > | workqueue call to prune_dcache(). Also have a separate sysctl to > | indicate by what percentage to reduce the dentry entries when this > | happens. > | > | Thanks for your input. If this sounds like a reasonable idea, I'll > | send out a patch. > | > | Cheers, > | Keyur. > > Hi Keyur, > > I like the idea. I've had people bring up the same issue, relating > to GFS2. This is especially true for doing du and similar ops on a > very large file system. This wasn't on GFS2, was it? > > Regards, > > Bob Peterson > Red Hat File Systems Hi Bob, Actually this was observed both on EXT3 and XFS. Only tmpfs is immune to the negative dentry caching problem, as might be expected :) Thanks, Keyur. -- 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
