page_size vs allocation_granularity

Corinna Vinschen
Wed Jul 22 08:47:41 GMT 2020

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,
> 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 Vinschen
Cygwin Maintainer

More information about the Cygwin-developers mailing list