All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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 Fixing private mappings 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 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.