delorie.com/archives/browse.cgi | search |
X-Recipient: | archive-cygwin AT delorie DOT com |
DomainKey-Signature: | a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id |
:list-unsubscribe:list-subscribe:list-archive:list-post | |
:list-help:sender:subject:to:references:from:message-id:date | |
:mime-version:in-reply-to:content-type | |
:content-transfer-encoding; q=dns; s=default; b=ifZHKpSiiHtAs3wM | |
LStHV25RqA/cVY+ZUO+hjqIBCANrN1QXJI9348ToGAZ8PCC5xit/gg69Wo3hHxgn | |
pqf+zXzQpdRrEf4Vi9AFMv+rNeYHowgwyQGEdei+wWiDCENAPeKXM9J5G7ixEpFt | |
pW7jo21iYKtUPF8VqqJ5h+T2Z0s= | |
DKIM-Signature: | v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id |
:list-unsubscribe:list-subscribe:list-archive:list-post | |
:list-help:sender:subject:to:references:from:message-id:date | |
:mime-version:in-reply-to:content-type | |
:content-transfer-encoding; s=default; bh=FCN6IntPKB6q92rwkExk/l | |
ZzgMY=; b=M6pBrSmEbCI77fXgM6kYm8IdEdq8+7BpttNTbwN3Mf3PulaN2dfnkl | |
6gtxoyZmchSD5YWflqGM+affipT9+vGU1wA8NKJ+GFenHwU/h9FN1JG+XX1qDmhS | |
+BzsV0twmY+OO+5LV4b2IVfPa7FyBtF5b0zJ/FTuuR9t+cr4yatJM= | |
Mailing-List: | contact cygwin-help AT cygwin DOT com; run by ezmlm |
List-Id: | <cygwin.cygwin.com> |
List-Subscribe: | <mailto:cygwin-subscribe AT cygwin DOT com> |
List-Archive: | <http://sourceware.org/ml/cygwin/> |
List-Post: | <mailto:cygwin AT cygwin DOT com> |
List-Help: | <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs> |
Sender: | cygwin-owner AT cygwin DOT com |
Mail-Followup-To: | cygwin AT cygwin DOT com |
Delivered-To: | mailing list cygwin AT cygwin DOT com |
Authentication-Results: | sourceware.org; auth=none |
X-Virus-Found: | No |
X-Spam-SWARE-Status: | No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS,TVD_RCVD_IP autolearn=ham version=3.3.2 spammy=now, HContent-Transfer-Encoding:8bit |
X-HELO: | glup.org |
Authentication-Results: | glup.org; dmarc=none header.from=glup.org |
Subject: | Re: Atomic mmap replacement |
To: | cygwin AT cygwin DOT com |
References: | <66bf4f86-4618-b9a3-3e33-2c240b9204d0 AT cornell DOT edu> <20180219090042 DOT GC3417 AT calimero DOT vinschen DOT de> <bf821c51-5cea-a3b9-3b24-812cdb8a7b9c AT cornell DOT edu> <20180219171914 DOT GA3619 AT calimero DOT vinschen DOT de> |
From: | John Hood <cgull AT glup DOT org> |
Message-ID: | <3a317ca2-c4d7-d5e2-a93a-4756df9f9b57@glup.org> |
Date: | Mon, 19 Feb 2018 20:03:55 -0500 |
User-Agent: | Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 |
MIME-Version: | 1.0 |
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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |