From: "Benjamin C.R. LaHaise" <blah@kvack.org>
To: Richard Guenther <richard.guenther@student.uni-tuebingen.de>
Cc: Linux Kernel List <linux-kernel@vger.rutgers.edu>,
glame-devel@lists.sourceforge.net, Linux-MM <linux-mm@kvack.org>
Subject: Re: mmap/munmap semantics
Date: Wed, 23 Feb 2000 10:58:41 -0500 (EST) [thread overview]
Message-ID: <Pine.LNX.3.96.1000223104315.3536A-100000@kanga.kvack.org> (raw)
In-Reply-To: <Pine.LNX.4.10.10002231137450.5002-100000@linux14.zdv.uni-tuebingen.de>
On Wed, 23 Feb 2000, Richard Guenther wrote:
> No, I do not want to extend the file. I want to do a mmap of a _part_
> (in the middle) of an existing and have this part automagically zeroed
> regardless if there was a hole (already zeroed) or some other data.
> With the mmap & read(/dev/zero) approach I can achieve this, but I do not
> know if it is portably (wrt to effectvieness).
It should be portable, but it still isn't as efficient as just dumping the
pages since it generates io.
> > > So for the first case we could add a flag to mmap like MAP_ZERO to
> > > indicate a zero-map (dirty).
> >
> > Or teach truncate about preallocation.
>
> ?? I do not understand this. Truncate does not operate on ranges in the
> middle of a file, no?
I think I see what you're trying to do now, so just ignore this part =)
> So how can I throw away a dirty (shared) mapping of a file without
> generating disk io? Remember, I do not care about the contents of the file
> at the mmap place.
> A possible solution would be to be able to convert a shared mapping to
> a private one? If I'm the only user of the shared mapping (so its a
> virtually private one) this should be easy - just "disconnect" it. In the
> other case I do not really know how to handle this.
The most portable and easiest way to achieve this behaviour right now is
to use individual files or shm segments for the shared mappings. Using
SysV shared memory will get you the most performance since it won't get
written back to disk early (like mmaped files). If that doesn't give you
enough space, I strongly recommend using 1 file per shared "segment",
since the semantics you get by truncating and then extending the mapping
are exactly what you want. As a bonus, this technique works on
filesystems that don't support files with holes =)
-ben
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
next prev parent reply other threads:[~2000-02-23 15:58 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-02-22 17:46 Richard Guenther
2000-02-22 18:36 ` James Antill
2000-02-22 18:41 ` Benjamin C.R. LaHaise
2000-02-23 10:57 ` Richard Guenther
2000-02-23 15:58 ` Benjamin C.R. LaHaise [this message]
2000-02-24 10:06 ` Richard Guenther
2000-02-22 21:48 ` Richard Gooch
2000-02-23 3:49 ` Eric W. Biederman
2000-02-23 11:14 ` Richard Guenther
2000-02-23 15:44 ` Jamie Lokier
2000-02-23 18:48 ` Stephen C. Tweedie
2000-02-24 2:35 ` Jamie Lokier
2000-02-24 12:13 ` Stephen C. Tweedie
2000-02-24 12:24 ` Richard Guenther
2000-02-24 13:51 ` Stephen C. Tweedie
2000-02-24 15:01 ` kernel
2000-02-24 15:03 ` Richard Guenther
2000-02-24 15:15 ` Jamie Lokier
2000-02-24 13:06 ` lars brinkhoff
2000-02-24 14:42 ` Jamie Lokier
2000-02-24 13:41 ` Eric W. Biederman
2000-02-24 13:49 ` Stephen C. Tweedie
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=Pine.LNX.3.96.1000223104315.3536A-100000@kanga.kvack.org \
--to=blah@kvack.org \
--cc=glame-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.org \
--cc=richard.guenther@student.uni-tuebingen.de \
/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