> > On Tue, Oct 20, 2015 at 09:06:08PM +0900, Namjae Jeon wrote: > > Hi Ted, > > > > I will check this issue. > > Thanks! > > To be clear, the commit that I bisected this down to was fixing a real > issue, so I'm not really blaming your commit. Furthermore, it wasn't > causing test failures until very recently, and part of this is > probably caused by a change in the test environment, and also probably > a change in the most recent kernels about how memory reclaim and how > we handle low memory situations. However, once I started seeing test > failures, I started looking harder for memory leaks, and it was clear > that we had memory leaks in the data=journal scenario starting with > 1ce01c4a199. > > Interestingly we're not seeing these memory leaks on the truncate > path, so I suspect the issue is in how collapse range is clearing > pages from the page cache, especially pages that were freshly written > to the journal by the commit but which hadn't yet been writtten to > disk and then marked as complete so we can allow the relevant > transaction to be checkpointed. (Although we're not leaking the > journal head structures, but only the buffer heads, so the story most > be a bit more complicated than that.) Okay, Thanks for sharing your view and points !! Currently I can reproduce memory leak issue without collase/insert/zero range. conditions like the following.(collase/insert/zero range are disable with -I -C -z option and add -y option instead of -W) 1. small size parition(1GB) 2. run fsx with these options "./fsx -N 30000 -o 128000 -l 500000 -r 4096 -t 512 -w 512 -Z -R -y -I -C -z testfile" And same result with generic/091 is showing (buffer_head leak) So I am starting to find root-cause base on your points. I will share the result or the patch. Thanks~ > > Cheers, > > - Ted > -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
