From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 59F13A00C5; Thu, 7 May 2020 13:58:04 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3D1E31DC1A; Thu, 7 May 2020 13:58:04 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id F294A1DC1A for ; Thu, 7 May 2020 13:58:02 +0200 (CEST) IronPort-SDR: RUFX4JSbIs8HoiU9c7zBMDpkM5ZBJdYi7v1nmKRkr1//cYjJ5wkPM2cu/3Afuwc4tGeGagUV+l cxY/N4OK5wCQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 May 2020 04:58:01 -0700 IronPort-SDR: uXQ9jUnoBvNNbcjHodtrO+a+ZKPikQTFsbzTkdM9/iXEQjHiK0LPnNQgbe0rnw6ethU9S3Rzqw uh5mRaYecLJg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,363,1583222400"; d="scan'208";a="251495734" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.252.140.79]) ([10.252.140.79]) by fmsmga008.fm.intel.com with ESMTP; 07 May 2020 04:57:59 -0700 To: Dmitry Kozlyuk Cc: dev@dpdk.org, "Dmitry Malloy (MESHCHANINOV)" , Narcisa Ana Maria Vasile , Fady Bader , Tal Shnaiderman , Thomas Monjalon , Harini Ramakrishnan , Omar Cardona , Pallavi Kadam , Ranjit Menon , John McNamara , Marko Kovacevic References: <20200410164342.1194634-1-dmitry.kozliuk@gmail.com> <20200428235015.2820677-1-dmitry.kozliuk@gmail.com> <20200428235015.2820677-9-dmitry.kozliuk@gmail.com> <41f2a43d-2c22-f408-f21f-64932e4d5bb8@intel.com> <20200506022017.5adf0b90@Sovereign> <25dea975-7df1-6ad4-70b5-2ba5fd9647fa@intel.com> <20200507005353.28ec18da@Sovereign> From: "Burakov, Anatoly" Message-ID: <01ca68f9-dbed-9fc6-df1e-2e0e1f5cc097@intel.com> Date: Thu, 7 May 2020 12:57:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200507005353.28ec18da@Sovereign> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v4 8/8] eal/windows: implement basic memory management 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" On 06-May-20 10:53 PM, Dmitry Kozlyuk wrote: > On 2020-05-06 10:46 GMT+0100 Burakov, Anatoly wrote: >> On 06-May-20 12:20 AM, Dmitry Kozlyuk wrote: >>> On 2020-05-05 17:24 GMT+0100 Burakov, Anatoly wrote: >>>> On 29-Apr-20 12:50 AM, Dmitry Kozlyuk wrote: >>>> Lots of duplication... I wonder if it would be possible to share at >>>> least some of this code in common. Tracking down bugs because of >>>> duplicated code desync is always a pain... >>> >>> This was the main question of the cover letter :) >>> Dmitry Malloy explained to me recently that even internally Windows has >>> no notion of preallocated hugepages and "memory types" (as memseg_primary_init >>> describes it). Since Windows EAL is not going to support multi-process any >>> time soon (if ever), maybe these reservations are not needed and memory manger >>> should create MSLs and enforce socket limits dynamically? This way most of the >>> duplicated code can be removed, I think. Or does MSL reservation serve some >>> other purposes? >> >> MSL reservation serves the purpose of dynamically expanding memory >> usage. > > But expansion is limited during init, because alloc_more_mem_on_socket() > works with existing MSLs, correct? No going to change anything there, just > trying to understand MM internals. Yes, system memory MSLs will stay the same for the duration of the program, they are not allocated on the fly. External memory will create/destroy MSLs but those too aren't allocated dynamically - there's a fixed number of MSLs, and if you run out, well, you're out of luck. So no, the MSLs themselves don't get allocated/deallocated at runtime *if* they belong to system (internal) memory. > >> If there is no notion of NUMA nodes or multiple page sizes, then >> you can greatly simplify the code, but you'd still need *some* usage of >> MSL's if you plan to support dynamically allocating memory, or >> supporting externally allocated memory (i assume it's out of scope for >> now, since you can't do IOVA as VA). > > Windows is NUMA-aware and it supports both 2MB and 1GB hugepages (although > Windows EAL does not at the moment, because Win32 API is not yet official). > What I meant is that Windows does not reserve hugepages like Linux does with > vm.nr_hugepages or hugepage-related kernel options. So logic duplicated from > Linux EAL makes sense for Windows. The bulk of it can be extracted to some > common file, but it will not be truly common, rather "everything but > FreeBSD". Against it is a point that Windows MM may change significantly, but > I honestly can't come up with an example of how can those duplicated parts > may require adjustments. Fair enough. It's your EAL, you can do as you like :) > >> So, yes, you could greatly simplify the memory management code *if* you >> were to go FreeBSD way and not allow dynamic page reservation. If you >> do, however, then i would guess that you'd end up writing something >> that's largely similar to existing Linux code (minus multiprocess) and >> so would just be duplicating effort. > -- Thanks, Anatoly