This is the mail archive of the cygwin 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: Process map and fork problems


Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > I think all the affected machines have 4GB memory installed, but the
> > option may not have been default when they were installed.
> 
> They never are default.  Default is 2 Gigs application VM, 2 Gigs
> kernelÌ memory space.  Specifying /3Gb means 3 Gigs application VM
> vs. 1 Gig kernelÌ memory space.  That's not always a good thing
> since it could lead to kernel memory pool exhaustion.

I meant "not default in the base install image provided by corporate IT". 
I'll have to ask if they have some special procedure to switch it on.

> > With /3GB you mean 4GT (aka PAE), right?  And 32bit is without PAE?
> 
> No, PAE works differently, using different calls.  I'm talking abut
> the normal 32 bit address space of a 32 bit CPU.

Hmm.  Microsoft's 4GT documentation makes you believe that /3GB and PAE is
always coupled, though.  But then even non-/3GB might laready use some PAE
facilities anyway.  But I guess it's not important.

> It can only know its own heap.  But keep in mind that the heap can
> be differently sized in different applications.  The heap only *starts*
> as a 384Meg heap, it could easly grow in big apps (gcc, emacs, ...)
> when calling sbrk.

So it can grow only so much until it runs into the first loaded DLL above? 
Or does it fragment into yet unused areas then?


Regards,
Achim.

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