RE: memory leak: data=journal and {collapse,insert,zero}_range

[Namjae Jeon <namjae.jeon@samsung.com>]

> 
> 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
>