Possible memory leak in the kernel (contigmalloc)

[Bennett, Ciunas]

Hi,
The only other activity that is running is the csh script  that is inserting and removing the kernel module.
I am not using the VM for any other purpose but to run this test.
In my tests the correlation between memory allocation and moving to inactive list can be seen.
I don't think any other process is creating the inactive memory.
Thanks.

-----Original Message-----
From: Konstantin Belousov [mailto:kostikbel at gmail.com] 
Sent: Tuesday, October 30, 2018 10:12 AM
To: Bennett, Ciunas <ciunas.bennett at intel.com>
Cc: freebsd-stable at freebsd.org
Subject: Re: Possible memory leak in the kernel (contigmalloc)

On Tue, Oct 30, 2018 at 09:46:59AM +0000, Bennett, Ciunas wrote:
> Hi,
> 
> I was debugging the issue by viewing the free ques "sysctl 
> vm.phys_free" and also using "show page" in ddb. The inactive memory 
> is never being released back into the free que. I thought that when 
> inactive memory reaches a certain threshold that the kernel will start 
> reclaiming and move it to the free list? In my program this is not 
> happening, the program uses free memory (contigmalloc), and then it is 
> put into the inactive que (contiigfree) when the program frees it.
Contigfree() does not release memory into inactive queue.  By definition, inactive pages have valid content, which is not possible for the pages freed by contigfree().
contigfree()->kmem_free()->kmem_unback()->vm_page_free().


> This inactive memory is never released by the kernel, and the inactive 
> que grows until all the memory is in this que. I have attached a xml 
> sheet that shows the memory usage in the system.
Inactive memory is not freed, it makes no sense as far as there is valid content, which is either not recoverable (anon memory or dirty file
pages) or high-cost to restore (clean file pages, need to re-read from disk).  Inactive is processed by pagedaemon when system has memory deficit, and either inactive pages are written to swap, or written to their file backing storage.

I suspect that you have other activities on your system going on, which cause creation of the inactive memory and unrecoverable fragmentation.
Note that contigmalloc() tries to do defragmentation to satisfy requests, but this is not always possible.


> Ciunas.
> 
> -----Original Message-----
> From: Konstantin Belousov [mailto:kostikbel at gmail.com]
> Sent: Friday, October 26, 2018 9:13 PM
> To: Bennett, Ciunas <ciunas.bennett at intel.com>
> Cc: freebsd-stable at freebsd.org
> Subject: Re: Possible memory leak in the kernel (contigmalloc)
> 
> On Wed, Oct 24, 2018 at 04:27:52PM +0000, Bennett, Ciunas wrote:
> > Hello,
> > 
> > I have encountered an issue with a kernel application that I have 
> > written, the issue might be caused by a memory leak in the kernel.
> > The application allocates and deallocates contiguous memory using
> > contigmalloc() and contigfree(). The application will fail after a 
> > period of time because there is not enough free contiguous memory 
> > left. There could be an issue with the freeing of memory when using 
> > the contigfree() function.
> >
> 
> It is unlikely that there is an issue with a leak, but I would be not surprised if your allocation/free pattern would cause fragmentation on free lists that results in contigmalloc(9) failures after.
> 
> Look at the vmstat -z/vmstat -m output to see uma and malloc stats.
> More interesting for your case can be the output from
> 	sysctl vm.phys_free
> which provides information about the free queues and order of free pages on them.
> --------------------------------------------------------------
> Intel Research and Development Ireland Limited Registered in Ireland 
> Registered Office: Collinstown Industrial Park, Leixlip, County 
> Kildare Registered Number: 308263
> 
> 
> This e-mail and any attachments may contain confidential material for 
> the sole use of the intended recipient(s). Any review or distribution 
> by others is strictly prohibited. If you are not the intended 
> recipient, please contact the sender and delete all copies.


--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.