X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=T4KsptPBsmSzTKKUvZlUtdRNb6SY9PtQpeA4SES3j0MoLZ70/rarA
	Ke+zHOZucf8xVqGk2KfqIYZ9boYQmlmPh73QgpzpkgdKk/g0weV0cDRAyAtEAvmZ
	fnM4qjQm+Yvx6zRqbupdq6WUc35MUtXCk+axTrUGDiKbUd4oeUdydU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=OEpmFxw85OnBru2akbXzt6OGoJI=; b=YzlGkdivj5b9Fr+bd9MOfcaGCxU7
	0LYV0nGrKhvXtp2e/327amcZG49DiOGF12M9vTtrNBFdAtJru1Y+QiKHHXkAGTg7
	1e32UP3UCgeEgod14ahVUNwtBtzwWmeAwdm1HkvlhYYQn2Je1UovzPrSb2X4RQ2e
	Nu0xDPsoJvhFj30=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-96.6 required=5.0 tests=BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_PBL,RDNS_DYNAMIC autolearn=ham version=3.3.2 spammy=microsoft's, microsofts, Microsoft's, Microsofts
X-HELO: calimero.vinschen.de
Date: Wed, 20 Apr 2016 16:06:25 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Process map and fork problems
Message-ID: <20160420140625.GA25668@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <loom DOT 20160420T121651-786 AT post DOT gmane DOT org> <20160420104633 DOT GA26118 AT calimero DOT vinschen DOT de> <loom DOT 20160420T124825-644 AT post DOT gmane DOT org> <20160420111431 DOT GB13570 AT calimero DOT vinschen DOT de> <loom DOT 20160420T131743-463 AT post DOT gmane DOT org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM"
Content-Disposition: inline
In-Reply-To: <loom.20160420T131743-463@post.gmane.org>
User-Agent: Mutt/1.5.24 (2015-08-30)

--yrj/dFKFPuw6o+aM
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Apr 20 11:24, Achim Gratz wrote:
> 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.
> >=20
> > They never are default.  Default is 2 Gigs application VM, 2 Gigs
> > kernel=CC=87 memory space.  Specifying /3Gb means 3 Gigs application VM
> > vs. 1 Gig kernel=CC=87 memory space.  That's not always a good thing
> > since it could lead to kernel memory pool exhaustion.
>=20
> I meant "not default in the base install image provided by corporate IT".=
=20
> I'll have to ask if they have some special procedure to switch it on.
>=20
> > > With /3GB you mean 4GT (aka PAE), right?  And 32bit is without PAE?
> >=20
> > No, PAE works differently, using different calls.  I'm talking abut
> > the normal 32 bit address space of a 32 bit CPU.
>=20
> 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.
>=20
> > 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.
>=20
> So it can grow only so much until it runs into the first loaded DLL above=
?=20
> Or does it fragment into yet unused areas then?

It can't fragment, it can only grow.  The Unix heap management doesn't
have the notion of multiple application heaps.  There's only the sbrk
call to raise or shrink the size of the heap.


Corinna

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

--yrj/dFKFPuw6o+aM
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXF4zhAAoJEPU2Bp2uRE+gaHkQAKHUp78vCzh7nTCX8ihgqIrK
tleedLnQLUlX2nLYjasWjRHS5zeLEC+yrFer9WCP4KwZlksUG9Y838UnNTF8KgWr
+xH14ZBxFTfWLHS19oCUWVWOKWYDtKS3vwjUX+7ShZEKgbyWg+l09uU90UDyv3UU
CYYNWqABOHgLwLs0VfbBViDYvvFuM0qwUgQ0xGWx8jC48CBix8U1wbIF5otx1kXu
EFbCbZ0aDh7OShV1A90LELlbaHE54ECUPFetUPZ/0maQB+yOyM5eg2HvJZABcPjE
Xwcrftsf27gEyvaNaWD+txI2uhAmiKFHnsFPvY1UUbxQQkNqP+YGm2UU7ARQMqms
E/Vd83aqjejyTLAw5qGZvx35yrs+R6Q4+kAym2qpnvbEWYK+TAskWvnkO+Wi4+5E
UEfQXEpzuMdnp1AQF7N4rDYsks+JDhPiYoZBLUYtbUAZq6xkN4wMPMx4iaNh2dqH
B1cvr9gc9pWPgGBBwDoNsaquyWBOLspJI/5C63lArnMIl3FUrt4JJ9H+Bvrs5Dm+
vioy+nZwnE/Bd9bak8z17qKj9yzFx4HFVOaHqdZ6KWQYrkN163FDY8jUIwEVJrea
rAp5zbLQaJnIqZJBglJArj3OXANhQu4od7JhfZpHnyBQvIYyx2BXhBS2VA/kh1eR
AY8gjJCGB5VltMJOvrCW
=llHx
-----END PGP SIGNATURE-----

--yrj/dFKFPuw6o+aM--