From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.135]) by sourceware.org (Postfix) with ESMTPS id 915E8389244C for ; Wed, 22 Jul 2020 08:47:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 915E8389244C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=cygwin.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=corinna-cygwin@cygwin.com Received: from calimero.vinschen.de ([217.91.18.234]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MTzrW-1kNul31BgI-00R2Dr for ; Wed, 22 Jul 2020 10:47:43 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id C49F1A81007; Wed, 22 Jul 2020 10:47:41 +0200 (CEST) Date: Wed, 22 Jul 2020 10:47:41 +0200 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: page_size vs allocation_granularity Message-ID: <20200722084741.GS16360@calimero.vinschen.de> Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <3ac8f341-1dbe-b407-de64-4a2d5c191e68@cornell.edu> <20200722083327.GR16360@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200722083327.GR16360@calimero.vinschen.de> X-Provags-ID: V03:K1:YK5mg8JmgA0MKdABA9j9u6fMKIQvf0cBYLbZSc44TGs1G5m/ra8 KADInMFaeI7wI1xutjOg4iDAnYv5APwYJ5Ew58xLT4X/Y0XT10U+z+hwj6IUOa3jZiG13j6 0U05GW4FXXZQ8ALnEDWj4ut7qqi090QZfnqK7IqmMdsRCdySJRn89Sea2aayxmm3SltIHdu HVbEXDUQE2bPSNMLyAY/Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:TlbImd5YzMY=:KOINIpA9w3EMH2a6APjtKU 0fSxrCVhucb0SQ0fU50Q2oo1tJD8qy+Sd2hp0zaNDv7S9vSgMlPA2pnNBa1CkEd2/lAnPmNw0 dHndyQG+qOTUNiGjYr1A6wAAcA9ZK8Ihi1N/yv8S/laZz3b3yalpCwTKVIC07a1/LDKhyZrMH gvxO0WeG4pTqAFbaGyvtyiMeqz3UZLoDIw8yPLNY3+63PxfKF66VnNYbraulBCKQjegrZpG+/ KQTq854ch94JrKfpQTsubHuONuG9qtlc3CTpPjCry/zEZOTh7WO71h9IetFsOnDK3+m901ATM VSr9J5meDC2wEIlasknGNQKcEKXgab7iOwg8LmxdG79E12D7KNlt3veT2fhmQOw/MvgpH8xO3 V3ces2wWTIS40LW5mgWqIH/cIkkiyoKN1sgblfcZPfeXh93X1Nw46KNvV2NtllbBd6PeRXm2Y wiZZeHeEbqmUjGFcqa7QQKH18BnrTj20zZP6Ma2EW+dX2XCiOuf+EScnMfaO6OAIoUlON80F4 N5M6dwmfvUHIK6lPvE4Jt0l0RbbL8Rk6+DFcdu1LpGQ2BOtbZ15CQrAUqQDhfZiAuF9yn1n11 oHLAQNU6Jm+MUKx+2BbypVGk5bMGd4QYmRIjYvQW011KNHsg7TMknd/k85zjTgZU8Bz0QxgrW oBW2gAoaZIlaE1VBTACXEp5odw/KvzB/MX7iEOc0Z7kb+lMUVTU4OoSplyQGTC7xtdJ8YH2km izt61XsNazU2IYu9ktKAiuleUUGWytt0Gs4ZVkpnJWL9VM3osJ5uJ2Js0TpW7EHY+Z+UZATzZ /J1VWnbEuy+X9KhTdqwWjhZIh+RqC5uTPXiRdExiXEYUfDRC1BwJLx5nHhfggxUyVGd80iUPm qWnUGsfXY6i6F/soalIw== X-Spam-Status: No, score=-99.4 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NEUTRAL, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2020 08:47:46 -0000 On Jul 22 10:33, Corinna Vinschen wrote: > On Jul 21 18:40, Ken Brown via Cygwin-developers wrote: > > Hi Corinna, > > > > I'm curious about the design decision that causes sysconf(_SC_PAGESIZE) to > > return wincap.allocation_granularity() rather than wincap.page_size(). > > Changing this would improve Linux compatibility, I think, but maybe it would > > have some bad consequences that I'm not aware of. > > It was a long and hard process to move from 4K to 64K pagesize, with > lots of loaded discussions. The Cygwin mailing list archives will > show a lot of this in the 200X years. > > It was the only way to make mmap 99% POSIX-conformant. Consider, for > instance this: > > pagesize = sysconf(_SC_PAGESIZE); > addr = mmap (NULL, pagesize, PROT_READ | PROT_WRITE, > MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); > addr2 = mmap (addr + pagesize, pagesize, PROT_READ | PROT_WRITE, > MAP_FIXED | MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); > > On Windows, this fails with pagesize = 4K, but it works with pagesize = > 64K, because of that idiotic Windows allocation granularity. Almost > all POSIX expectations are automagically fixed by using the granularity > as pagesize in a POSIX sense. > > There's only one problem left: While you can only allocate usefully in > 64K steps, the size of the memory area allocated for a file is only 4K > aligned, thus leaving the remainder of the 64K block unmapped. > > This problem could be fixed back in 32 bit times by adding the > AT_ROUND_TO_PAGE mapping. Very unfortunately, the 64 bit Windows > designer decided to keep the braindead 64K allocation granularity > but to drop the AT_ROUND_TO_PAGE flag, thus removing the only chance > to make this single situation POSIX-compatible as well. Oh, and there was a short hope a few months back when I discovered the new memory management PLACEHOLDER flags. Unfortunately Mappings within placeholders are only allowed to be anonymous mappings, so there's no relief for file backed mappings. Corinna -- Corinna Vinschen Cygwin Maintainer