From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81448 invoked by alias); 19 Feb 2018 22:33:55 -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 81439 invoked by uid 89); 19 Feb 2018 22:33:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: limerock02.mail.cornell.edu Received: from limerock02.mail.cornell.edu (HELO limerock02.mail.cornell.edu) (128.84.13.242) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Feb 2018 22:33:52 +0000 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite4.serverfarm.cornell.edu [10.16.197.9]) by limerock02.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id w1JMXoSc031904 for ; Mon, 19 Feb 2018 17:33:50 -0500 Received: from [192.168.0.15] (mta-68-175-129-7.twcny.rr.com [68.175.129.7] (may be forged)) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id w1JMXnLM026136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 19 Feb 2018 17:33:49 -0500 Subject: Re: Atomic mmap replacement To: cygwin@cygwin.com References: <66bf4f86-4618-b9a3-3e33-2c240b9204d0@cornell.edu> <20180219090042.GC3417@calimero.vinschen.de> <20180219171914.GA3619@calimero.vinschen.de> From: Ken Brown Message-ID: Date: Mon, 19 Feb 2018 22:33:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180219171914.GA3619@calimero.vinschen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Cornell-Gauge: Gauge=XXXXX X-PMX-CORNELL-AUTH-RESULTS: dkim-out=none; X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00215.txt.bz2 On 2/19/2018 12:19 PM, Corinna Vinschen wrote: > On Feb 19 08:22, Ken Brown wrote: >> On 2/19/2018 4:00 AM, Corinna Vinschen wrote: >>> On Feb 17 22:37, Ken Brown wrote: >>>> Some code in emacs wants to reserve a chunk of address space with a big >>>> PROT_NONE anonymous mapping, and then carve it up into separate mappings >>>> associated to segments of a file. This fails on Cygwin. Here's a test case >>>> that illustrates the problem: >>>> [...] >>> Several limitations in the Windows kernel disallow this: >>> >>> - It doesn't allow to unmap parts of a map, only the entire map as a >>> whole. >>> Cygwin has a workaround: If you unmap parts of a map it just keeps >>> track of this and sets the protection of the affected pages to >>> PAGE_NOACCESS. In case of anonymous mappings, it even recycles them >>> potentially for other mappings. >>> >>> - It also disallows to re-map any allocated or mapped mamory for another >>> purpose. >>> >>> So this part of the POSIX specs for mmap: >>> >>> "The mapping established by mmap() shall replace any previous mappings >>> for those whole pages containing any part of the address space of the >>> process starting at pa and continuing for len bytes" >>> >>> can't be implemented with Windows means. >>> >>> The only workaround possible would be to handle this *exact* scenario as >>> a special case in Cygwin's mmap: If the new mapping falls in the middle >>> of an existing mapping and if the original mapping was an anonymous >>> mapping with PROT_NONE page protection, then > > 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 :} That doesn't sound great. In the meantime, the problem was solved on the emacs side by doing what you suggested in your previous email: > - unmap the old mapping > - remap the unaffected parts as separate anonymous mapping > - map the affected parts for the requested file mapping But in the emacs application it's simpler, because there are no unaffected parts, so step 2 can be skipped. Thanks. Ken -- 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