From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by dpdk.org (Postfix) with ESMTP id 810775A49 for ; Thu, 23 Jul 2015 10:13:34 +0200 (CEST) Received: by wibxm9 with SMTP id xm9so136880889wib.1 for ; Thu, 23 Jul 2015 01:13:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=87k17hizENzxUQCqJDhb6UAwNSMbBwgwSkGHPYMjhjY=; b=XxYF+YV7oIlsFWHWShkdpSIEYZgVqnn0jtWKqEGwGwlPlUEodxdCwSMFx+qX++W5r6 z04s5lKh1rXayxz/lWS42u1bl/s/If/j6k3rvzzm8sdB8xuTpyycENFPX29e4ZQfuSvO HDkmPd25Ju4w8phj+5xTr/roH2I8eeHxwlaiNIMNEo71GgxvG8WQkGjYhsDta5vwrcRT HL6NnRC10PLJ7KakxyPLypBa0MNq9Wd4/mwiOf7AVtL+W38fCS+E4+ttuFatGtJ0Kfdg 3VvFW9vY65I1eTfzzWe/MeRuVR7bUPpf+pkwKII0+3EH9GVOjxMz5e/ueSptzAvV+0cQ 32bg== X-Gm-Message-State: ALoCoQmfTqvIHVLk8gwBVMqns4+u6PUvzOpKLlLZ1rEkCg9r1QHjlka2Vpf8HMw+GnHbxF2FfHgg X-Received: by 10.195.11.168 with SMTP id ej8mr13159609wjd.150.1437639214345; Thu, 23 Jul 2015 01:13:34 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by smtp.gmail.com with ESMTPSA id ex8sm6249074wjc.34.2015.07.23.01.13.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jul 2015 01:13:33 -0700 (PDT) From: Thomas Monjalon To: "Gonzalez Monroy, Sergio" Date: Thu, 23 Jul 2015 10:12:21 +0200 Message-ID: <1504831.JexCQJ5PJA@xps13> Organization: 6WIND User-Agent: KMail/4.14.8 (Linux/4.0.4-2-ARCH; KDE/4.14.8; x86_64; ; ) In-Reply-To: <55B09913.8040100@intel.com> References: <3797202.NyZr8XgqE1@xps13> <55B09913.8040100@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 08:13:34 -0000 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. > - 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.