public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: John Hood <cgull@glup.org>
To: cygwin@cygwin.com
Subject: Re: Atomic mmap replacement
Date: Tue, 20 Feb 2018 01:04:00 -0000	[thread overview]
Message-ID: <3a317ca2-c4d7-d5e2-a93a-4756df9f9b57@glup.org> (raw)
In-Reply-To: <20180219171914.GA3619@calimero.vinschen.de>



On 02/19/2018 12:19, Corinna Vinschen wrote:
> On second thought, we *could* do this, if the pages have been mmapped
> before(*).  Unfortunately this would require a *major* revamp of the
> page handling in mmap.  We would have to keep the mapping of every
> single 64K page separate.
>
> I.e., requesting a file mapping of 256K at offset 0 on the POSIX level
> would have to be handled as four Windows file mappings under the hood:
>
> 1. a 64K file mapping at offset 0
> 2. a 64K file mapping at offset 65536
> 3. a 64K file mapping at offset 131072
> 4. a 64K file mapping at offset 196608
>
> A request to mmap another 64K page to the third mapping in this example
> could then be done by unmapping the third mapping and replace it with
> the requested mapping.
>
> I'm not sure this is feasible.  It would complicate and slow down the
> code especially for big mappings; one call to NtCreateSection and one to
> NtMapViewOfSection per 64K page, plus the overhead of making sure that
> all mappings are in the right, sequential order in memory.  Plus the
> overhead of having to remap a lot more mappings in forked children.  The
> "Cygwin is slow" meme would get another interesting facet :}
>
I work on an app that does something like this (but for other reasons, 
and it'll never be ported to Cygwin).

I'm also dubious, but I'll point out that it'd probably be reasonable to 
do this only on regions that are mapped PROT_NONE initially, other 
regions could work as they do now.  That'd help performance in the 
common case.  Also, if Windows has a way to prevent use of a region 
other than creating a mapping, Cygwin could perhaps emulate PROT_NONE 
mappings without actually creating a mapping (at the cost of even more 
code complexity, probably).

regards,

   --jh


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

  parent reply	other threads:[~2018-02-20  1:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-18  3:37 Ken Brown
2018-02-19  9:01 ` Corinna Vinschen
2018-02-19 13:22   ` Ken Brown
2018-02-19 17:19     ` Corinna Vinschen
2018-02-19 22:33       ` Ken Brown
2018-02-20 10:31         ` Corinna Vinschen
2018-02-20  1:04       ` John Hood [this message]
2018-02-20 10:47         ` Corinna Vinschen

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=3a317ca2-c4d7-d5e2-a93a-4756df9f9b57@glup.org \
    --to=cgull@glup.org \
    --cc=cygwin@cygwin.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 read-only IMAP folder(s) and NNTP newsgroup(s).