From: ebiederm+eric@npwt.net (Eric W. Biederman)
To: "Stephen C. Tweedie" <sct@dcs.ed.ac.uk>
Cc: linux-mm@kvack.org
Subject: Re: Fixing private mappings
Date: 25 Apr 1998 00:30:53 -0500 [thread overview]
Message-ID: <m1hg3imprm.fsf@flinx.npwt.net> (raw)
In-Reply-To: "Stephen C. Tweedie"'s message of Fri, 24 Apr 1998 21:37:45 +0100
>>>>> "ST" == Stephen C Tweedie <sct@dcs.ed.ac.uk> writes:
ST> Hi,
ST> On 23 Apr 1998 17:03:02 -0500, ebiederm+eric@npwt.net (Eric
ST> W. Biederman) said:
ST> No --- in the context of a MAP_PRIVATE mapping, only in-memory writes to
ST> the privately mapped virtual address space count as write references.
Got it.
I still like the semantics I defined, but if they aren't defined as
map_private I won't worry about it for the present.
Sometime it might be worth it/fun implementing a MAP_SNAPSHOT, but I
won't worry about that for the present.
ST> Yep, but we are not required to support non-page-aligned maps at all, so
ST> hacking it for special read-only cases is no big deal. Doing a search
ST> for all overlapping mapped pages would be far too slow.
I think in the general case I could implement it without overhead and
in the common a.out case within a factor of 2, and in the worst case
within a factor of 4 (assuming a restriction of 1k alignment). And
this is primarly memcpy cost there should be no need for extra disk
i/o.
The scheme I'm playing with using will share the same case as extra
huge file I/O (> 16TB), and in the common case should perform
identically to what we have now.
Thanks for setting me straight. It hadn't been my intention to play
with mmap until I found this really weird use of that mmap makes of
the page_cache, so I really wasn't prepared for that one.
Eric
prev parent reply other threads:[~1998-04-25 5:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-04-23 5:06 Eric W. Biederman
1998-04-23 8:28 ` Rik van Riel
1998-04-23 15:12 ` Benjamin C.R. LaHaise
1998-04-23 22:03 ` Eric W. Biederman
1998-04-24 20:37 ` Stephen C. Tweedie
1998-04-25 5:30 ` Eric W. Biederman [this message]
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=m1hg3imprm.fsf@flinx.npwt.net \
--to=ebiederm+eric@npwt.net \
--cc=linux-mm@kvack.org \
--cc=sct@dcs.ed.ac.uk \
/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