From owner-freebsd-stable@freebsd.org Tue Oct 30 09:47:12 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7BF7110DD29B for ; Tue, 30 Oct 2018 09:47:12 +0000 (UTC) (envelope-from ciunas.bennett@intel.com) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "fmsmga104.fm.intel.com", Issuer "COMODO RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F2D97A7B7 for ; Tue, 30 Oct 2018 09:47:11 +0000 (UTC) (envelope-from ciunas.bennett@intel.com) X-Amp-Result: CLEAN X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2018 02:47:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,444,1534834800"; d="xml'?bin'?scan'72,48,208?xlsx'72,48,208,72,48?rels'72,48,208,72,48"; a="99939186" Received: from irsmsx108.ger.corp.intel.com ([163.33.3.3]) by fmsmga002.fm.intel.com with ESMTP; 30 Oct 2018 02:47:00 -0700 Received: from irsmsx112.ger.corp.intel.com (10.108.20.5) by IRSMSX108.ger.corp.intel.com (163.33.3.3) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 30 Oct 2018 09:47:00 +0000 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.144]) by irsmsx112.ger.corp.intel.com ([169.254.1.93]) with mapi id 14.03.0415.000; Tue, 30 Oct 2018 09:46:59 +0000 From: "Bennett, Ciunas" To: Konstantin Belousov CC: "freebsd-stable@freebsd.org" Subject: RE: Possible memory leak in the kernel (contigmalloc) Thread-Topic: Possible memory leak in the kernel (contigmalloc) Thread-Index: AdRrtbzKvvQI2iPZToSPdiaEvmHIXQBqhpgAALREjJA= Date: Tue, 30 Oct 2018 09:46:59 +0000 Message-ID: <770FD3608C9E864796AB46CB37B561B1BE0B4096@irsmsx105.ger.corp.intel.com> References: <770FD3608C9E864796AB46CB37B561B1BDFCF0CD@IRSMSX101.ger.corp.intel.com> <20181026201230.GV5335@kib.kiev.ua> In-Reply-To: <20181026201230.GV5335@kib.kiev.ua> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMmE5ZWI5ZWEtMzEyZi00ZTQzLWFkOGMtZGU2ZDA5NGY3NTg3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiQkU5RG5kRThxeUcxRjJTTG05cG9oMlpMTktrRUFtK1wvS0RPY0xpMjZUZkh2eEwzQTkzazk3TmcxQnlWMjdpNUIifQ== x-originating-ip: [163.33.239.182] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 09:47:12 -0000 Hi, I was debugging the issue by viewing the free ques "sysctl vm.phys_free" an= d 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 ke= rnel will start reclaiming and move it to the free list? In my program this is not happening, the program uses free memory (contigma= lloc), and then it is put into the inactive que (contiigfree) when the prog= ram frees it. 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. Ciunas. -----Original Message----- From: Konstantin Belousov [mailto:kostikbel@gmail.com] = Sent: Friday, October 26, 2018 9:13 PM To: Bennett, Ciunas Cc: freebsd-stable@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 surpr= ised if your allocation/free pattern would cause fragmentation on free list= s 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 s= ole 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.