From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
To: Jerin Jacob <jerinjacobk@gmail.com>
Cc: "Burakov, Anatoly" <anatoly.burakov@intel.com>,
"Thomas Monjalon" <thomas@monjalon.net>,
"Morten Brørup" <mb@smartsharesystems.com>,
"Bruce Richardson" <bruce.richardson@intel.com>,
dpdk-dev <dev@dpdk.org>, "Olivier Matz" <olivier.matz@6wind.com>,
"Andrew Rybchenko" <andrew.rybchenko@oktetlabs.ru>,
"Honnappa Nagarahalli" <honnappa.nagarahalli@arm.com>,
"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
"Ferruh Yigit" <ferruh.yigit@intel.com>,
"Jerin Jacob" <jerinj@marvell.com>,
"Akhil Goyal" <gakhil@marvell.com>,
"Narcisa Ana Maria Vasile" <navasile@linux.microsoft.com>,
"Dmitry Malloy (MESHCHANINOV)" <dmitrym@microsoft.com>,
"Pallavi Kadam" <pallavi.kadam@intel.com>
Subject: Re: [dpdk-dev] [PATCH] parray: introduce internal API for dynamic arrays
Date: Thu, 17 Jun 2021 01:58:06 +0300 [thread overview]
Message-ID: <20210617015806.6452221e@sovereign> (raw)
In-Reply-To: <CALBAE1NsBid=Nv+ONjnsjBYgv8P1rLdytra96S9aDG1SSGGSvQ@mail.gmail.com>
2021-06-16 18:29 (UTC+0530), Jerin Jacob:
> On Wed, Jun 16, 2021 at 5:52 PM Burakov, Anatoly
> <anatoly.burakov@intel.com> wrote:
> >
> > On 16-Jun-21 10:42 AM, Jerin Jacob wrote:
> > > On Tue, Jun 15, 2021 at 12:18 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > >>
> > >> 14/06/2021 17:48, Morten Brørup:
> > >>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> > >>> It would be much simpler to just increase RTE_MAX_ETHPORTS to something big enough to hold a sufficiently large array. And possibly add an rte_max_ethports variable to indicate the number of populated entries in the array, for use when iterating over the array.
> > >>>
> > >>> Can we come up with another example than RTE_MAX_ETHPORTS where this library provides a better benefit?
> > >>
> > >> What is big enough?
> > >> Is 640KB enough for RAM? ;)
> > >
> > > If I understand it correctly, Linux process allocates 640KB due to
> > > that fact currently
> > > struct rte_eth_dev rte_eth_devices[RTE_MAX_ETHPORTS] is global and it
> > > is from BSS.
> > >
> > > If we make this from heap i.e use malloc() to allocate this memory
> > > then in my understanding Linux
> > > really won't allocate the real page for backend memory until unless,
> > > someone write/read to this memory.
> > >
> > > i.e it will be free virtual memory using Linux memory management help.
> > > If so, we can keep large values for RTE_MAX_ETHPORTS
> > > without wasting any "real" memory even though the system has a few ports.
> > >
> > > Thoughts?
> > >
> >
> > mmap works this way with anonymous memory, i'm not so sure about
> > malloc()'ed memory.
>
> Looking at online documentation scatters over the internet, sbrk(), is
> based on demand paging.
> So I am not sure as well. I am also not sure how we can write some
> test case to verify it.
> Allocating a huge memory through malloc() not failing, not sure it is
> due to demand pagging
> or Linux over commit feature or combination of both,
>
> if mmap works in this way, we could have EAL abstraction for such
> memory alloc like
> eal_malloc_demand_page() or so and if Windows also supports it.
>
>
>
> > Plus, we can't base these decisions on what Linux
> > does because we support other OS's. Do they do this as well?
>
> + Windows OS maintainers
Yes, Windows uses demand paging.
Is it true that BSS is eagerly allocated (i. e. RAM consumed)? If not, and it
shouldn't be, malloc() isn't needed unless hugepages are required.
next prev parent reply other threads:[~2021-06-16 22:58 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-14 10:58 Thomas Monjalon
2021-06-14 12:22 ` Morten Brørup
2021-06-14 13:15 ` Bruce Richardson
2021-06-14 13:32 ` Thomas Monjalon
2021-06-14 14:59 ` Ananyev, Konstantin
2021-06-14 15:48 ` Jerin Jacob
2021-06-15 6:52 ` Thomas Monjalon
2021-06-15 8:00 ` Jerin Jacob
2021-06-15 9:18 ` Thomas Monjalon
2021-06-15 9:33 ` Ananyev, Konstantin
2021-06-15 9:50 ` Thomas Monjalon
2021-06-15 10:08 ` Ananyev, Konstantin
2021-06-15 14:02 ` Thomas Monjalon
2021-06-15 14:37 ` Honnappa Nagarahalli
2021-06-14 15:54 ` Ananyev, Konstantin
2021-06-17 13:08 ` Ferruh Yigit
2021-06-17 14:58 ` Ananyev, Konstantin
2021-06-17 15:17 ` Morten Brørup
2021-06-17 16:12 ` Ferruh Yigit
2021-06-17 16:55 ` Morten Brørup
2021-06-18 10:21 ` Ferruh Yigit
2021-06-17 17:05 ` Ananyev, Konstantin
2021-06-18 9:14 ` Morten Brørup
2021-06-18 10:47 ` Ferruh Yigit
2021-06-18 11:16 ` Morten Brørup
2021-06-18 10:28 ` Ferruh Yigit
2021-06-17 15:44 ` Ferruh Yigit
2021-06-18 10:41 ` Ananyev, Konstantin
2021-06-18 10:49 ` Ferruh Yigit
2021-06-21 11:06 ` Ananyev, Konstantin
2021-06-21 12:10 ` Morten Brørup
2021-06-21 12:30 ` Ananyev, Konstantin
2021-06-21 13:28 ` Morten Brørup
[not found] ` <DM6PR11MB4491D4F6FAFDD6E8EEC2A78F9A099@DM6PR11MB4491.namprd11.prod.outlook .com>
2021-06-22 8:33 ` Ananyev, Konstantin
2021-06-22 10:01 ` Morten Brørup
2021-06-22 12:13 ` Ananyev, Konstantin
2021-06-22 13:18 ` Morten Brørup
2021-06-21 14:10 ` Ferruh Yigit
2021-06-21 14:38 ` Ananyev, Konstantin
2021-06-21 15:56 ` Ferruh Yigit
2021-06-21 18:17 ` Ananyev, Konstantin
2021-06-21 14:05 ` Ferruh Yigit
2021-06-21 14:42 ` Ananyev, Konstantin
2021-06-21 15:32 ` Ferruh Yigit
2021-06-21 15:37 ` Ananyev, Konstantin
2021-06-14 15:48 ` Morten Brørup
2021-06-15 6:48 ` Thomas Monjalon
2021-06-15 7:53 ` Morten Brørup
2021-06-15 8:44 ` Bruce Richardson
2021-06-15 9:28 ` Thomas Monjalon
2021-06-16 9:42 ` Jerin Jacob
2021-06-16 11:27 ` Morten Brørup
2021-06-16 12:00 ` Jerin Jacob
2021-06-16 13:02 ` Bruce Richardson
2021-06-16 15:01 ` Morten Brørup
2021-06-16 17:40 ` Bruce Richardson
2021-06-16 12:22 ` Burakov, Anatoly
2021-06-16 12:59 ` Jerin Jacob
2021-06-16 22:58 ` Dmitry Kozlyuk [this message]
2021-06-14 13:28 ` Thomas Monjalon
2021-06-16 11:11 ` Burakov, Anatoly
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=20210617015806.6452221e@sovereign \
--to=dmitry.kozliuk@gmail.com \
--cc=anatoly.burakov@intel.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=dmitrym@microsoft.com \
--cc=ferruh.yigit@intel.com \
--cc=gakhil@marvell.com \
--cc=honnappa.nagarahalli@arm.com \
--cc=jerinj@marvell.com \
--cc=jerinjacobk@gmail.com \
--cc=konstantin.ananyev@intel.com \
--cc=mb@smartsharesystems.com \
--cc=navasile@linux.microsoft.com \
--cc=olivier.matz@6wind.com \
--cc=pallavi.kadam@intel.com \
--cc=thomas@monjalon.net \
/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).