From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 781045B38 for ; Tue, 30 Apr 2019 11:32:47 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Apr 2019 02:32:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,413,1549958400"; d="scan'208";a="166210758" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.237.220.113]) ([10.237.220.113]) by fmsmga002.fm.intel.com with ESMTP; 30 Apr 2019 02:32:45 -0700 To: msantana@redhat.com, dev@dpdk.org References: <2e847465-48d3-4df7-6a2c-e9903d131219@redhat.com> From: "Burakov, Anatoly" Message-ID: Date: Tue, 30 Apr 2019 10:32:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <2e847465-48d3-4df7-6a2c-e9903d131219@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] Hugepages not being deleted X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 09:32:47 -0000 On 23-Apr-19 4:15 PM, Michael Santana Francisco wrote: > Hello, > > I am currently working on a patch to fix the eal_flags_autotest test as > it currently fails on many platforms. > I have made some progress, however I stumbled upon a possible issue with > EAL and hugepages. > Looking at the code and some documentation it appears to me that > hupepages are supposed to be automatically deleted on dynamic memory > mode as the dpdk process exits. > The test however reports that this is not happening. Apologies, this email has slipped through the cracks. Hugepages not being deleted can happen in certain circumstances (such as drivers allocating things and not freeing them later), and there's little DPDK EAL can do to fix it - if the memory is used, it's not safe to just pull it out from under whoever is using it. The best you can do is find what is allocating that memory, and fix the problem at the source. > > This can be shown by: > > bash# export DPDK_TEST=eal_flags_autotest > bash# ./build/app/test/dpdk-test > ... > Error - hugepage files for memtest1 were not deleted! > Error in test_file_prefix() > Test Failed > bash# ls /dev/hugepages/ #hugetlbfs is mounted on /dev/hugepages > memtest1map_0  memtest1map_1  memtest1map_2  memtest1map_3 > memtest1map_4  memtest1map_5  memtest1map_6  memtest1map_7 > memtest1map_8  rtemap_0 > > To me it appears that the hugepages are in fact not being deleted > correctly. > Is this an anomaly or is anyone else seeing this issue as well? > > Michael Santana > > > Note, if you are running on a system with less than 8 cores please see > patch > https://github.com/Maickii/dpdk-2/commit/7cfad856611e3ded4050f670ec11d1b2e17851d8.patch > > -- Thanks, Anatoly From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 1FB89A0679 for ; Tue, 30 Apr 2019 11:32:50 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 15C1E5F1A; Tue, 30 Apr 2019 11:32:49 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 781045B38 for ; Tue, 30 Apr 2019 11:32:47 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Apr 2019 02:32:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,413,1549958400"; d="scan'208";a="166210758" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.237.220.113]) ([10.237.220.113]) by fmsmga002.fm.intel.com with ESMTP; 30 Apr 2019 02:32:45 -0700 To: msantana@redhat.com, dev@dpdk.org References: <2e847465-48d3-4df7-6a2c-e9903d131219@redhat.com> From: "Burakov, Anatoly" Message-ID: Date: Tue, 30 Apr 2019 10:32:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <2e847465-48d3-4df7-6a2c-e9903d131219@redhat.com> Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] Hugepages not being deleted X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190430093244.QJZIYzTr9u6T2gibwbf7-mk9lGanZTHlT0lEG1dM85E@z> On 23-Apr-19 4:15 PM, Michael Santana Francisco wrote: > Hello, > > I am currently working on a patch to fix the eal_flags_autotest test as > it currently fails on many platforms. > I have made some progress, however I stumbled upon a possible issue with > EAL and hugepages. > Looking at the code and some documentation it appears to me that > hupepages are supposed to be automatically deleted on dynamic memory > mode as the dpdk process exits. > The test however reports that this is not happening. Apologies, this email has slipped through the cracks. Hugepages not being deleted can happen in certain circumstances (such as drivers allocating things and not freeing them later), and there's little DPDK EAL can do to fix it - if the memory is used, it's not safe to just pull it out from under whoever is using it. The best you can do is find what is allocating that memory, and fix the problem at the source. > > This can be shown by: > > bash# export DPDK_TEST=eal_flags_autotest > bash# ./build/app/test/dpdk-test > ... > Error - hugepage files for memtest1 were not deleted! > Error in test_file_prefix() > Test Failed > bash# ls /dev/hugepages/ #hugetlbfs is mounted on /dev/hugepages > memtest1map_0  memtest1map_1  memtest1map_2  memtest1map_3 > memtest1map_4  memtest1map_5  memtest1map_6  memtest1map_7 > memtest1map_8  rtemap_0 > > To me it appears that the hugepages are in fact not being deleted > correctly. > Is this an anomaly or is anyone else seeing this issue as well? > > Michael Santana > > > Note, if you are running on a system with less than 8 cores please see > patch > https://github.com/Maickii/dpdk-2/commit/7cfad856611e3ded4050f670ec11d1b2e17851d8.patch > > -- Thanks, Anatoly