From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Yongseok Koh <yskoh@mellanox.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"andras.kovacs@ericsson.com" <andras.kovacs@ericsson.com>,
"laszlo.vadkeri@ericsson.com" <laszlo.vadkeri@ericsson.com>,
"keith.wiles@intel.com" <keith.wiles@intel.com>,
"benjamin.walker@intel.com" <benjamin.walker@intel.com>,
"bruce.richardson@intel.com" <bruce.richardson@intel.com>,
Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [dpdk-dev] [RFC v2 00/23] Dynamic memory allocation for DPDK
Date: Thu, 25 Jan 2018 16:18:43 +0000 [thread overview]
Message-ID: <c1638317-2d32-76d1-dbd8-aaa3a6c94935@intel.com> (raw)
In-Reply-To: <63712223-C6E5-4319-9958-86445D38F076@mellanox.com>
On 23-Jan-18 10:33 PM, Yongseok Koh wrote:
>
>> On Dec 19, 2017, at 3:14 AM, Anatoly Burakov <anatoly.burakov@intel.com> wrote:
> [...]
>> Quick outline of all changes done as part of this patchset:
>>
>> * Malloc heap adjusted to handle holes in address space
>> * Single memseg list replaced by multiple expandable memseg lists
>> * VA space for hugepages is preallocated in advance
>
> Hi Anatoly,
>
> I haven't looked through your patchset yet but quick question. As far as I
> understand, currently EAL remaps virtual addresses to make VA layout matches PA
> layout. I'm not sure my expression is 100% correct.
>
> By your comment above, do you mean VA space for all available physical memory
> will always be contiguous?
>
> I have been curious about why VA space is fragmented in DPDK.
>
> Thanks,
> Yongseok
>
>
Hi Yongseok,
Yes and no. Currently, VA space is allocated opportunistically - EAL
tries to allocate VA space to match PA space layout, but due to varying
page sizes and contiguous segment sizes, it doesn't always turn out that
way - hence possible VA fragmentation even if underlying PA space may be
contiguous.
With this patchset, we kind of do it the other way around - we allocate
contiguous VA space segment per socket, per page size, and then we map
physical memory into it, without regard for PA layout whatsoever. So,
assuming all VA space is mapped, VA space is contiguous while PA space
may or may not be (depending on underlying physical memory layout and if
you're using IOMMU).
However, since this is hotpluggable (and hot-unpluggable) memory, we can
have holes in *mapped* VA space, even though *allocated* VA space would
be contiguous within the boundaries of page size. You can think of it
this way - we preallocate segments per page size, per socket, so e.g. on
a machine with 2 sockets and 2MB and 1GB pages enabled, you'll get 4
contiguous chunks of VA space that is available for mapping. Underlying
mappings may or may not be contiguous (i.e. mapped segments might become
fragmented if you allocate/free memory all over the pace), but they will
reside within the same contiguous chunk of VA space.
Hope that answers your question :)
--
Thanks,
Anatoly
next prev parent reply other threads:[~2018-01-25 16:18 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-19 11:14 Anatoly Burakov
2017-12-19 11:14 ` [dpdk-dev] [RFC v2 01/23] eal: move get_virtual_area out of linuxapp eal_memory.c Anatoly Burakov
2017-12-19 11:14 ` [dpdk-dev] [RFC v2 02/23] eal: add function to report number of detected sockets Anatoly Burakov
2017-12-19 11:14 ` [dpdk-dev] [RFC v2 03/23] eal: add rte_fbarray Anatoly Burakov
2017-12-19 11:14 ` [dpdk-dev] [RFC v2 04/23] eal: move all locking to heap Anatoly Burakov
2017-12-19 11:14 ` [dpdk-dev] [RFC v2 05/23] eal: protect malloc heap stats with a lock Anatoly Burakov
2017-12-19 11:14 ` [dpdk-dev] [RFC v2 06/23] eal: make malloc a doubly-linked list Anatoly Burakov
2017-12-19 11:14 ` [dpdk-dev] [RFC v2 07/23] eal: make malloc_elem_join_adjacent_free public Anatoly Burakov
2017-12-19 11:14 ` [dpdk-dev] [RFC v2 08/23] eal: add "single file segments" command-line option Anatoly Burakov
2017-12-19 11:14 ` [dpdk-dev] [RFC v2 09/23] eal: add "legacy memory" option Anatoly Burakov
2017-12-19 11:14 ` [dpdk-dev] [RFC v2 10/23] eal: read hugepage counts from node-specific sysfs path Anatoly Burakov
2017-12-19 11:14 ` [dpdk-dev] [RFC v2 11/23] eal: replace memseg with memseg lists Anatoly Burakov
2017-12-19 11:14 ` [dpdk-dev] [RFC v2 12/23] eal: add support for dynamic memory allocation Anatoly Burakov
2017-12-19 11:14 ` [dpdk-dev] [RFC v2 13/23] eal: make use of dynamic memory allocation for init Anatoly Burakov
2017-12-19 11:14 ` [dpdk-dev] [RFC v2 14/23] eal: add support for dynamic unmapping of pages Anatoly Burakov
2017-12-19 11:14 ` [dpdk-dev] [RFC v2 15/23] eal: add API to check if memory is physically contiguous Anatoly Burakov
2017-12-19 11:14 ` [dpdk-dev] [RFC v2 16/23] eal: enable dynamic memory allocation/free on malloc/free Anatoly Burakov
2017-12-19 11:14 ` [dpdk-dev] [RFC v2 17/23] eal: add backend support for contiguous memory allocation Anatoly Burakov
2017-12-19 11:14 ` [dpdk-dev] [RFC v2 18/23] eal: add rte_malloc support for allocating contiguous memory Anatoly Burakov
2017-12-19 11:14 ` [dpdk-dev] [RFC v2 19/23] eal: enable reserving physically contiguous memzones Anatoly Burakov
2017-12-19 11:14 ` [dpdk-dev] [RFC v2 20/23] eal: make memzones use rte_fbarray Anatoly Burakov
2017-12-19 11:14 ` [dpdk-dev] [RFC v2 21/23] mempool: add support for the new memory allocation methods Anatoly Burakov
2017-12-19 11:14 ` [dpdk-dev] [RFC v2 22/23] vfio: allow to map other memory regions Anatoly Burakov
2017-12-19 11:14 ` [dpdk-dev] [RFC v2 23/23] eal: map/unmap memory with VFIO when alloc/free pages Anatoly Burakov
2017-12-19 15:46 ` [dpdk-dev] [RFC v2 00/23] Dynamic memory allocation for DPDK Stephen Hemminger
2017-12-19 16:02 ` Burakov, Anatoly
2017-12-19 16:06 ` Stephen Hemminger
2017-12-19 16:09 ` Burakov, Anatoly
2017-12-21 21:38 ` Walker, Benjamin
2017-12-22 9:13 ` Burakov, Anatoly
2017-12-26 17:19 ` Walker, Benjamin
2018-02-02 19:28 ` Yongseok Koh
2018-02-05 10:03 ` Burakov, Anatoly
2018-02-05 10:18 ` Nélio Laranjeiro
2018-02-05 10:36 ` Burakov, Anatoly
2018-02-06 9:10 ` Nélio Laranjeiro
2018-02-14 2:01 ` Yongseok Koh
2018-02-14 9:32 ` Burakov, Anatoly
2018-02-14 18:13 ` Yongseok Koh
2018-01-13 14:13 ` Burakov, Anatoly
2018-01-23 22:33 ` Yongseok Koh
2018-01-25 16:18 ` Burakov, Anatoly [this message]
2018-02-14 8:04 ` Thomas Monjalon
2018-02-14 10:07 ` Burakov, Anatoly
2018-04-25 16:02 ` Burakov, Anatoly
2018-04-25 16:12 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c1638317-2d32-76d1-dbd8-aaa3a6c94935@intel.com \
--to=anatoly.burakov@intel.com \
--cc=andras.kovacs@ericsson.com \
--cc=benjamin.walker@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=keith.wiles@intel.com \
--cc=laszlo.vadkeri@ericsson.com \
--cc=thomas@monjalon.net \
--cc=yskoh@mellanox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).