From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4763 invoked by alias); 20 Feb 2018 10:47:42 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 3756 invoked by uid 89); 20 Feb 2018 10:47:41 -0000 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 Received: from mail-n.franken.de (HELO drew.franken.de) (193.175.24.27) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 20 Feb 2018 10:47:40 +0000 Received: from perth.hirmke.de (aquarius.franken.de [193.175.24.89]) by mail-n.franken.de (Postfix) with ESMTP id 998D4721E280D for ; Tue, 20 Feb 2018 11:47:37 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by perth.hirmke.de (Postfix) with ESMTP id 77768861B98 for ; Tue, 20 Feb 2018 11:47:37 +0100 (CET) X-Spam-Score: -2.9 Received: from perth.hirmke.de ([127.0.0.1]) by localhost (perth.hirmke.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8JuqitnfnfNi for ; Tue, 20 Feb 2018 11:47:36 +0100 (CET) Received: from calimero.vinschen.de (calimero.vinschen.de [192.168.129.6]) by perth.hirmke.de (Postfix) with ESMTP id B8B91861A3D for ; Tue, 20 Feb 2018 11:47:36 +0100 (CET) Received: by calimero.vinschen.de (Postfix, from userid 500) id AAC97A8068F; Tue, 20 Feb 2018 11:47:36 +0100 (CET) Date: Tue, 20 Feb 2018 10:47:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Atomic mmap replacement Message-ID: <20180220104736.GG3417@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <66bf4f86-4618-b9a3-3e33-2c240b9204d0@cornell.edu> <20180219090042.GC3417@calimero.vinschen.de> <20180219171914.GA3619@calimero.vinschen.de> <3a317ca2-c4d7-d5e2-a93a-4756df9f9b57@glup.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) X-SW-Source: 2018-02/txt/msg00220.txt.bz2 --3Gf/FFewwPeBMqCJ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2868 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" Content-length: 833 -----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--