From: Bruce Richardson <bruce.richardson@intel.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
Karmarkar Suyash <skarmarkar@sonusnet.com>
Subject: Re: [dpdk-dev] DDPK use of MAP_FIXED in mmap
Date: Tue, 9 Dec 2014 16:04:11 +0000 [thread overview]
Message-ID: <20141209160411.GA5844@bricha3-MOBL3> (raw)
In-Reply-To: <20141209152634.GE28871@hmsreliant.think-freely.org>
On Tue, Dec 09, 2014 at 10:26:34AM -0500, Neil Horman wrote:
> On Mon, Dec 08, 2014 at 07:02:38PM +0000, Karmarkar Suyash wrote:
> > Hello,
> >
> > In DPDK when we use mmap why are we passing the MAP_FIXED flag when Linux man page itself says that the option is discouraged? Any specific reason for passing the MAP_FIXED flag?
> >
> Because theres nothing wrong with doing so. The man page says its discouraged
> because it creates less portable applications (due to the fact that not all
> operating systems support MAP_FIXED). Given that we currently only support BSD
> and Linux however, and given that MAP_FIXED was added to POSIX for
> XSI compliant systems, it seems like a reasonable thing to use, as we will most
> likely never run into a system that won't support it
> Neil
>
Whatever about portability, I thing the best reason to avoid it is given in the
quote from the map page given below: "If the memory region specified by addr and
len overlaps pages of any existing mapping(s), then the overlapped part of the
existing mapping(s) will be discarded." i.e. an mmap with MAP_FIXED can silently
discard an existing mapping. This can lead to some strange behaviour for the
unwary.
/Bruce
> >
> > http://linux.die.net/man/2/mmap
> >
> > MAP_FIXED
> > Don't interpret addr as a hint: place the mapping at exactly that address. addr must be a multiple of the page size. If the memory region specified by addr and len overlaps pages of any existing mapping(s), then the overlapped part of the existing mapping(s) will be discarded. If the specified address cannot be used, mmap() will fail. Because requiring a fixed address for a mapping is less portable, the use of this option is discouraged.
> >
> >
> > Regards
> > Suyash Karmarkar
> >
next prev parent reply other threads:[~2014-12-09 16:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-08 19:02 Karmarkar Suyash
2014-12-09 9:55 ` Bruce Richardson
2014-12-09 18:29 ` Xie, Huawei
2014-12-09 15:26 ` Neil Horman
2014-12-09 16:04 ` Bruce Richardson [this message]
2014-12-09 18:22 ` Neil Horman
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=20141209160411.GA5844@bricha3-MOBL3 \
--to=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=nhorman@tuxdriver.com \
--cc=skarmarkar@sonusnet.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).