From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id E36BAC332 for ; Thu, 23 Jul 2015 11:29:59 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 23 Jul 2015 02:29:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,529,1432623600"; d="scan'208";a="768087694" Received: from smonroyx-mobl.ger.corp.intel.com (HELO [10.237.221.12]) ([10.237.221.12]) by fmsmga002.fm.intel.com with ESMTP; 23 Jul 2015 02:29:53 -0700 Message-ID: <55B0B411.5050903@intel.com> Date: Thu, 23 Jul 2015 10:29:53 +0100 From: "Gonzalez Monroy, Sergio" User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Thomas Monjalon References: <3797202.NyZr8XgqE1@xps13> <55B09913.8040100@intel.com> <1504831.JexCQJ5PJA@xps13> In-Reply-To: <1504831.JexCQJ5PJA@xps13> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] libhugetlbfs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 09:30:00 -0000 On 23/07/2015 09:12, Thomas Monjalon wrote: > 2015-07-23 08:34, Gonzalez Monroy, Sergio: >> On 22/07/2015 11:40, Thomas Monjalon wrote: >>> Sergio, >>> >>> As the maintainer of memory allocation, would you consider using >>> libhugetlbfs in DPDK for Linux? >>> It may simplify a part of our memory allocator and avoid some potential >>> bugs which would be already fixed in the dedicated lib. >> I did have a look at it a couple of months ago and I thought there were >> a few issues: >> - get_hugepage_region/get_huge_pages only allocates default size huge pages >> (you can set a different default huge page size with environment >> variables but no >> support for multiple sizes) plus we have no guarantee on physically >> contiguous pages. > Speaking about that, we don't always need contiguous pages. > Maybe we should take it into account when reserving memory. > Some flags DMA (locked physical pages that are not swappable) and CONTIGUOUS > may be considered. Sure. I think I also mentioned this as possible future work in the Dynamic Memzones RFC. >> - That leave us with >> hugetlbfs_unlinked_fd/hugetlbfs_unlinked_fd_for_size. These APIs >> wouldn't simplify a lot the current code, just the allocation of the >> pages themselves >> (ie. creating a file in hugetlbfs mount). >> Then there is the issue with multi-process; because they return a >> file descriptor while >> unlinking the file, we would need some sort of Inter-Process >> Communication to pass >> the descriptors to secondary processes. >> - Not a big deal but AFAIK it is not possible to have multiple mount >> points for the same >> hugepage size, and even if you do, hugetlbfs_find_path_for_size >> returns always the >> same path (ie. first found in list). >> - We still need to parse /proc/self/pagemap to get physical address of >> mapped hugepages. >> >> I guess that if we were to push for a new API such as >> hugetlbfs_fd_for_size, we could use >> it for the hugepage allocation, but we still would have to parse >> /proc/self/pagemap to get >> physical address and then order those hugepages. >> >> Thoughts? > Why not extending the API and pushing our code to this lib? > It would allow to share the maintenance. > > The same move could be done to libpciaccess. I don't disagree with the idea of using libhugetlbfs, I just tried to point out that it's not just a drop in replacement. Sergio