All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olivier Matz <olivier.matz@6wind.com>
To: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>,
	Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: dev@dpdk.org
Subject: Re: memory allocation requirements
Date: Fri, 15 Apr 2016 09:12:42 +0200	[thread overview]
Message-ID: <5710946A.9080001@6wind.com> (raw)
In-Reply-To: <570FB996.4070801@intel.com>

Hi,

On 04/14/2016 05:39 PM, Sergio Gonzalez Monroy wrote:
>> Just to mention that some evolutions [1] are planned in mempool in
>> 16.07, allowing to populate a mempool with several chunks of memory,
>> and still ensuring that the objects are physically contiguous. It
>> completely removes the need to allocate a big virtually contiguous
>> memory zone (and also physically contiguous if not using
>> rte_mempool_create_xmem(), which is probably the case in most of
>> the applications).
>>
>> Knowing this, the code that remaps the hugepages to get the largest
>> possible physically contiguous zone probably becomes useless after
>> the mempool series. Changing it to only one mmap(file) in hugetlbfs
>> per NUMA socket would clearly simplify this part of EAL.
>>
> 
> Are you suggesting to make those changes after the mempool series
> has been applied but keeping the current memzone/malloc behavior?

I wonder if the default property of memzone/malloc which is to
allocate physically contiguous memory shouldn't be dropped. It could
remain optional, knowing that allocating a physically contiguous zone
larger than a page cannot be guaranteed.

But yes, I'm in favor of doing these changes in eal_memory.c, it would
drop a lot a complex code (all rtemap* stuff), and today I'm not seeing
any big issue of doing it... maybe we'll find one during the
discussion :)

Regards,
Olivier

  reply	other threads:[~2016-04-15  7:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-13 16:03 memory allocation requirements Thomas Monjalon
2016-04-13 17:00 ` Wiles, Keith
2016-04-14  8:48 ` Sergio Gonzalez Monroy
2016-04-14 14:46 ` Olivier MATZ
2016-04-14 15:39   ` Sergio Gonzalez Monroy
2016-04-15  7:12     ` Olivier Matz [this message]
2016-04-15  8:47       ` Sergio Gonzalez Monroy
2016-05-18 10:28 ` Alejandro Lucero

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=5710946A.9080001@6wind.com \
    --to=olivier.matz@6wind.com \
    --cc=dev@dpdk.org \
    --cc=sergio.gonzalez.monroy@intel.com \
    --cc=thomas.monjalon@6wind.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.