On Tue, May 28, 2013 at 02:12:26AM -0400, Keyur Govande wrote: > On Sun, May 26, 2013 at 7:23 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > On Fri, May 24, 2013 at 11:12:50PM -0400, Keyur Govande wrote: > >> On Mon, May 20, 2013 at 6:53 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > >> > On Sun, May 19, 2013 at 11:50:55PM -0400, Keyur Govande wrote: > >> >> 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. .... > >> Also, setting a bad value for the knob would negatively impact file-IO > >> performance, which on a spinning disk isn't guaranteed anyway. The > >> current situation tanks memory performance which is more unexpected to > >> a normal user. > > > > Which is precisely why a knob is the wrong solution. If it's > > something a normal, unsuspecting user has problems with, then it > > needs to be handled automatically by the kernel. Expecting users who > > don't even know what a dentry is to know about a magic knob that > > fixes a problem they don't even know they have is not an acceptable > > solution. > > > > The first step to solving such a problem is to provide a > > reproducable, measurable test case in a simple script that > > demonstrates the problem that needs solving. If we can reproduce it > > at will, then half the battle is already won.... > > Here's a simple test case: https://gist.github.com/keyurdg/5660719 to > create a ton of dentry cache entries, and > https://gist.github.com/keyurdg/5660723 to allocate some memory. > > I kicked off 3 instances of fopen in 3 different prefixed directories. > After all the memory was filled up with dentry entries, I tried > allocating 4GB of memory. It took ~20s. If I turned off the dentry > generation programs and attempted to allocate 4GB again, it only took > 2s (because the memory was already free). Here's a quick graph of this > behavior: http://i.imgur.com/XhgX84d.png News at 11! Memory allocation when memory is full is slower than when it's empty! That's not what I was asking for. We were talking about negative dentry buildup and possibly containing that, not a strawman "I can fill all of memory with dentries by creating files" workload. IOWs, your example is not demonstrating the problem you complained about. We are not going to put a global limit on active dentries. If you really want a global dentry cache size limit or to ensure that certain processes have free memory available for use, then perhaps you should be looking at what you can control with cgroups. 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
