On Tue, May 28, 2013 at 12:42 PM, Keyur Govande <keyurgovande@xxxxxxxxx> wrote: > On Tue, May 28, 2013 at 6:49 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: >> 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. > > By passing in a mode of "r" like: "./fopen test1 r & ./fopen test2 r > &" you can create a ton of negative dentry cache entries. > >> >> 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 I looked through some older discussions like http://marc.info/?l=linux-fsdevel&m=131363083730886&w=2 it sounds like you might be OK with limiting the size of the "inactive cache" (nr_unused). I think that is a perfectly reasonable solution, because in my case, nr_unused bloating up is always the real issue. -- 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
