From: Andreas Baer <andreas_baer@gmx.de>
To: linux-kernel@vger.kernel.org
Subject: Memory-Mapping with LFS
Date: Fri, 26 Aug 2005 04:52:08 +0200 [thread overview]
Message-ID: <430E83D8.4050509@gmx.de> (raw)
Who is the memory mapping expert? :)
What are the current file size limits for memory mapping via glibc's
mmap() function on linux:
- for a native 32-Bit System not using LFS?
- for a native 32-Bit System using LFS?
- for a native 64-Bit System?
(linux-kernel >2.6, of course)
It would be nice if someone could tell me what I have to consider if I
want to use memory mapping for files. I'm currently a little bit
confused about it (information overflow :)). Personal opinions about
speed (maybe increase or decrease for large files) are also welcome.
--------------------------
The glibc documentation says:
"Since mmapped pages can be stored back to their file when physical
memory is low, it is possible to mmap files orders of magnitude larger
than both the physical memory and swap space. The only limit is address
space. The theoretical limit is 4GB on a 32-bit machine - however, the
actual limit will be smaller since some areas will be reserved for other
purposes. If the LFS interface is used the file size on 32-bit systems
is not limited to 2GB (offsets are signed which reduces the addressable
area of 4GB by half); the full 64-bit are available."
- I doubt that the full 64-Bit (something within Exabyte) are available
in practical use. Right or wrong?
I've also found an old kernel-list e-mail from 2004 that says:
"There is a limit per process in the kernel vm that prevent from
mmapping more than 512GB of data."
- Is this still true for the current kernel?
An example:
Let's presume the following case. I have an 8 GB file, 1 GB physical
memory and I want to use memory mapping for that file using LFS on a
32-Bit machine.
- Is it possible?
If yes, let's presume that I have 2 or more pointers, that are
frequently pointing to completely different places and switch the data
they are pointing to.
- How is it managed (by the kernel)? Through the pages, that are
mentioned in the glibc documentation above? Are these page operations
really faster than normal random file access (lseek etc)?
next reply other threads:[~2005-08-26 2:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-26 2:52 Andreas Baer [this message]
2005-08-30 17:35 ` Memory-Mapping with LFS Christoph Lameter
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=430E83D8.4050509@gmx.de \
--to=andreas_baer@gmx.de \
--cc=linux-kernel@vger.kernel.org \
/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