From owner-freebsd-arch@FreeBSD.ORG Wed Nov 30 16:24:28 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 429F0106566B for ; Wed, 30 Nov 2011 16:24:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 3FA258FC08 for ; Wed, 30 Nov 2011 16:24:26 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pAUGMa98015948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Nov 2011 18:22:36 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pAUGMa8V079107; Wed, 30 Nov 2011 18:22:36 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAUGMaAK079106; Wed, 30 Nov 2011 18:22:36 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 30 Nov 2011 18:22:36 +0200 From: Kostik Belousov To: Andreas Tobler Message-ID: <20111130162236.GA50300@deviant.kiev.zoral.com.ua> References: <4ED5BE19.70805@fgznet.ch> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MaxviSYR+Gwa10R8" Content-Disposition: inline In-Reply-To: <4ED5BE19.70805@fgznet.ch> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: FreeBSD Arch Subject: Re: powerpc64 malloc limit? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 16:24:28 -0000 --MaxviSYR+Gwa10R8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 30, 2011 at 06:24:41AM +0100, Andreas Tobler wrote: > All, >=20 > while working on gcc I found a very strange situation which renders my=20 > powerpc64 machine unusable. > The test case below tries to allocate that much memory as 'wanted'. The= =20 > same test case on amd64 returns w/o trying to allocate mem because the=20 > size is far to big. >=20 > I couldn't find the reason so far, that's why I'm here. >=20 > As Nathan pointed out the VM_MAXUSER_SIZE is the biggest on powerpc64: > #define VM_MAXUSER_ADDRESS (0x7ffffffffffff000UL) >=20 > So, I'd expect a system to return an allocation error when a user tries= =20 > to allocate too much memory and not really trying it and going to be=20 > unusable. Iow, I'd exepect the situation on powerpc64 as I see on amd64. >=20 > Can anybody explain me the situation, why do I not have a working limit= =20 > on powerpc64? >=20 > The machine itself has 7GB RAM and 12GB swap. The amd64 where I compared= =20 > has around 4GB/4GB RAM/swap. >=20 > TIA, > Andreas >=20 > include > #include >=20 > int main() > { > void *p; >=20 > p =3D (void*) malloc (1152921504606846968ULL); > if (p !=3D NULL) > printf("p =3D %p\n", p); >=20 > printf("p =3D %p\n", p); > return (0); > } First, you should provide details of what consistutes 'the unusable machine situation' on powerpc. That said, on amd64 the user map is between 0 and 0x7fffffffffff, which obviously less then the requested allocation size 0x100000000000000. If you look at the kdump output on amd64, you will see that malloc() tries to mmap() the area, fails and retries with obreak(). Default virtual memory limit is unlimited, so my best quess is that on amd64 vm_map_findspace() returns immediately. On powerpc64, I see no reason why vm_map_entry cannot be allocated, but please note that vm object and pages shall be only allocated on demand. So I am curious how does your machine breaks and where. --MaxviSYR+Gwa10R8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7WWEwACgkQC3+MBN1Mb4iCKwCfYPE7yETlYQz1KTZDJrcHQFYU eAkAnRLJQco/VXNjHPN3QMIYl1XyZo+C =Jwut -----END PGP SIGNATURE----- --MaxviSYR+Gwa10R8--