This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New Cygwin family member


On Feb 12 08:37, Ryan Johnson wrote:
> On 12/02/2013 6:00 AM, Corinna Vinschen wrote:
> >Hi guys,
> >
> >On Feb  8 14:55, Corinna Vinschen wrote:
> >>Another problem is the memory layout (the "fork" problem).  Fortunately
> >>we have a 43 bit address space now.  Here's is our current model, still
> >>open for discussion:
> >>
> >>- Keep clear of memory from 0x0 up to 0x0:7fffffff, and from
> >>   0x700:00000000 up to 0x7ff:ffffffff since these areas are used
> >>   by the OS for ... everything.
> >>
> >>- Cygwin thread stacks will be located between 0x0:80000000 and
> >>   0x0:ffffffff.  With a default stack size of 1 Meg, we have room for
> >>   2048 threads.
> >>
> >>- The Cygwin executables will be loaded to 0x1:00400000.
> >>
> >>- The Cygwin DLL will be loaded to 0x1:80040000.  That leaves 2 Gigs of
> >>   space for the executable.  The space from 0x1:8000000 up to
> >>   0x1:80040000 will be used for Cygwin's shared memory areas.
> >A slight change to the  memory model occured to me, which should drop
> >the potential DLL collisions even more:
> >
> >>- Other Cygwin distro DLLs are supposed to be rebased to the area
> >>   between 0x2:00000000 up to 0x3:ffffffff.  This is an area of 8 Gigs
> >>   for DLLs.  That should be enough for a while, I guess.
> >The memory slot from 0x2:00000000 up to 0x4:00000000 == 8 Gigs will be
> >used by rebase{all}...
> >
> >...while ld's --auto-image-base will use the region from 0x4:00000000 up
> >to 0x6:00000000.
> >
> >This means, rebased DLLs will never collide with auto-image-based DLLs,
> >and both types of DLLs have a full 8 Gigs space each, which should be
> >enough for the forseeable future.
> >
> >>- The heap will be located at 0x4:00000000, and it will be 512Megs by
> >>   default.
> >The heap will then be located at 0x6:00000000, of course.
> >
> >>- Then ... a big void ...
> >>
> >>- Eventually, mmap's will be allocated from 0x700:00000000 downwards.
> >This means the VM space left for heap and mmaps is a mere 7152 Gigabyte,
> >about 7 Terabytes.  I hope that's ok, even for our friends on the
> >Fortran frontier.
> >
> >Comments?
> If I count correctly:
> - Total address space available is 8TB
> - Windows no-man's land regions occupy 2GB and 1TB, respectively
> - Cygwin thread stacks occupy 2GB
> - Executable image gets 2GB
> - distro and auto-image dlls together occupy 16GB (including some
> tens of MB for the cygwin dll and shared memory areas)

Not quite :)  You missed the fact that the Cygwin DLL is located
outside that region, at 0x1:80000000.  This includes Cygwin's
shared memory and allows a cygheap size of about 2 GiB.  Still,
that doesn't reduce the heap/mmap size at all, so there's still
7144 GB left.

> - heap/mmap area gets from 0x6: to 0x700:, which I compute as 7144GB
> 
> In other words, the proposed layout occupies only 20GB, or less than
> 0.3% of the address space. If somebody wants significantly more heap
> space, they'd have to brave the 1TB no-man's land and risk fork
> failures. Or, more likely, just wait for Intel and MS to bump the
> address space limit by a few powers of two (which should happen
> roughly when the "normal" amount of memory to have in a Windows box
> approaches 8TB). At that point, the heap/mmap area can easily take
> over the additional space.
> 
> What's not to like?
> Ryan

Yeah, that doesn't sound overly cramped, does it?


Corinna

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]