[dpdk-dev] [PATCH v4 8/8] eal/windows: implement basic memory management

Burakov, Anatoly anatoly.burakov at intel.com
Thu May 7 13:57:58 CEST 2020


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


More information about the dev mailing list