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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=enfN0jLVQcpFjM5hV1pQzAq3H4kFK2pCwHaEBxQ26YvoiyoS3wTsW
	nPIQ1KYQMLB5kLkG28xuMMEw791kNKo2arLZLlu1Ygg2a1VcpGDF86RYsGPMw9Ug
	A185bKThsGmTKxJtiifQsGENpRfRyd2HM8SYjJeIPeOGCNqIG0kIdw=
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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=UuUtsdwdbwJlTkSOlgkvnXaKDmc=; b=DV2QWPQsv1cRSxne/0pOjgfxunj6
	zOWxEMOQRqSxN9EHpnOJRuRAZ/wwrfGARMVnj7l5gD4rlVK+1q6XVehE/2JDf6m5
	tEU52mGk+TnrG+GDXrQ3a3cmRqSdAoD/IUjzXUeOTviTsURW0t4Br5VGFyZih72k
	1NumN8ezsW74w4w=
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=-101.9 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hood
X-HELO: drew.franken.de
X-Spam-Score: -2.9
Date: Tue, 20 Feb 2018 11:47:36 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Atomic mmap replacement
Message-ID: <20180220104736.GG3417@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-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> <3a317ca2-c4d7-d5e2-a93a-4756df9f9b57 AT glup DOT org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="3Gf/FFewwPeBMqCJ"
Content-Disposition: inline
In-Reply-To: <3a317ca2-c4d7-d5e2-a93a-4756df9f9b57@glup.org>
User-Agent: Mutt/1.9.2 (2017-12-15)

--3Gf/FFewwPeBMqCJ
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Feb 19 20:03, John Hood wrote:
>=20
>=20
> 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.
> >=20
> > 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:
> >=20
> > 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
> >=20
> > 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.
> >=20
> > 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 :}
> >=20
> I work on an app that does something like this (but for other reasons, and
> it'll never be ported to Cygwin).
>=20
> 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.

As far as I'm concerned, the problem is that we collect special cases
which raise the number of lines of code, getting more complicated and
less well debuggable, but still only work in some cases.

Assuming we'd do this at all, doing this per page *all* the time would
certainly lead to simpler code.  The big change affects the bookkeeping
code in the first place.  Right now we have a list of files (anonympous
mappings are one file) with a list of mappings per file attached.  In
theory, to support scenarios like this, the bookkeeping structure should
be changed to a hash or list of per-page structs.  So we would look at
maps starting at the page address, rather than starting at the file
descriptor the map is attached to.

I'm not opposed to change Cygwin's mmap this way, but it's a loooot of
work and there's so much to do in so limited a time...

If somebody would like to take a stab at this, I'd be pretty excited.
Fortunately the mmap code is collected in a single source file
winsup/cygwin/mmap.cc, so you only need limited insight in the Cygwin
code.  Help from my side is guaranteed.


Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--3Gf/FFewwPeBMqCJ
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlqL/MgACgkQ9TYGna5E
T6DsrA//b4XjehXhy9dqFDbZJRYx4voRMEjlOum05T2LMsbbO4yBNne5RePyXedR
6PzBHm+B/dlJMdxTCyetkB2oV5RFcCe4WepTBtBp73Md3upkW9hCJrnh9mzMS8zF
n6GYzqz1bQKHNgJzIeF/Xn/5tdMSUHJ4Ciy9Gpcdmq+l9gGCxDcvbZ3L/PmwhVv1
ur1sVxrMbQQUbaRjcpdkBORFK/7Ag3UrK+hSlKUr33WQMKGkFpU1pdw8CZ/+tX7H
o72+ylkdUMm395SXw87Ncr+EHB+we79Jw8u/hzjEanSzMeWyYWvrwjauUOnYUSLC
Ij7Vg6ygl1j4WC22peME1EGuxS8WWTxhU6JnJD5FxwqQ7C+SJp31N/WhXuOPji/Q
R5nBFh+MfBNSrM+abIEuY3Ay5xCbwFyRGp7/QE6FVOfFr3YRqykpBqOQpik3cn/v
hodBF9Nc2CK/hzhS2Ul2EerGA7i+KBhMjNhhQmlc5uPK6QxLgZoywzP40sNxHHHF
Wpo0hy4++av/3geDqLB+AWCcoYg13GMRZ/bPW4z1vEv/cBs/6WvTPpspvGsu2ZbF
KYq7ie2IkQQh24+ZqLjAjYmOs73arAvb+xecGLqNPRNWvCv2lbWi5mylNwKhUjmX
GzfqPzeXNxH5ypcpQDbe8fQLS7KtlJOLMBToj5hNbHcJcPQ92kQ=
=L2Gn
-----END PGP SIGNATURE-----

--3Gf/FFewwPeBMqCJ--