From owner-freebsd-arch@FreeBSD.ORG Wed Nov 30 17:10:03 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 2D366106566B for ; Wed, 30 Nov 2011 17:10:03 +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 B36728FC17 for ; Wed, 30 Nov 2011 17:10:02 +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 pAUH9bDa023632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Nov 2011 19:09:37 +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 pAUH9b5t079279; Wed, 30 Nov 2011 19:09:37 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAUH9acd079278; Wed, 30 Nov 2011 19:09: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 19:09:36 +0200 From: Kostik Belousov To: Andreas Tobler Message-ID: <20111130170936.GB50300@deviant.kiev.zoral.com.ua> References: <4ED5BE19.70805@fgznet.ch> <20111130162236.GA50300@deviant.kiev.zoral.com.ua> <4ED65F70.7050700@fgznet.ch> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6VIkwkuKQ8ml0fyB" Content-Disposition: inline In-Reply-To: <4ED65F70.7050700@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 17:10:03 -0000 --6VIkwkuKQ8ml0fyB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 30, 2011 at 05:53:04PM +0100, Andreas Tobler wrote: > On 30.11.11 17:22, Kostik Belousov wrote: > >On Wed, Nov 30, 2011 at 06:24:41AM +0100, Andreas Tobler wrote: > >>All, > >> > >>while working on gcc I found a very strange situation which renders my > >>powerpc64 machine unusable. > >>The test case below tries to allocate that much memory as 'wanted'. The > >>same test case on amd64 returns w/o trying to allocate mem because the > >>size is far to big. > >> > >>I couldn't find the reason so far, that's why I'm here. > >> > >>As Nathan pointed out the VM_MAXUSER_SIZE is the biggest on powerpc64: > >>#define VM_MAXUSER_ADDRESS (0x7ffffffffffff000UL) > >> > >>So, I'd expect a system to return an allocation error when a user tries > >>to allocate too much memory and not really trying it and going to be > >>unusable. Iow, I'd exepect the situation on powerpc64 as I see on amd64. > >> > >>Can anybody explain me the situation, why do I not have a working limit > >>on powerpc64? > >> > >>The machine itself has 7GB RAM and 12GB swap. The amd64 where I compared > >>has around 4GB/4GB RAM/swap. > >> > >>TIA, > >>Andreas > >> > >>include > >>#include > >> > >>int main() > >>{ > >> void *p; > >> > >> p =3D (void*) malloc (1152921504606846968ULL); > >> if (p !=3D NULL) > >> printf("p =3D %p\n", p); > >> > >> printf("p =3D %p\n", p); > >> return (0); > >>} > > > >First, you should provide details of what consistutes 'the unusable > >machine situation' on powerpc. >=20 > I can not login anymore, everything is stuck except the core control=20 > mechanisms for example the fan controller. >=20 > Top reports 'ugly' figures, below from a earlier try: >=20 > last pid: 6790; load averages: 0.78, 0.84, 0.86 up 0+00:34:52 > 22:42:29 47 processes: 1 running, 46 sleeping > CPU: 0.0% user, 0.0% nice, 15.4% system, 11.8% interrupt, 72.8% idle > Mem: 5912M Active, 570M Inact, 280M Wired, 26M Cache, 104M Buf, 352K Free > Swap: 12G Total, 9904M Used, 2383M Free, 80% Inuse, 178M Out >=20 > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU > COMMAND > 6768 andreast 1 52 01073741824G 6479M pfault 1 0:58 > 18.90% 31370. >=20 > And after my mem and swap are full I see swap_pager_getswapspace(16) fail= ed. >=20 > In this state I can only power-cycle the machine. >=20 > >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. >=20 > I would expect that the 'system' does not allow me to allocate that much= =20 > of ram. Does the issue with machine going into limbo reproducable with the code you posted ? Or, do you need to actually touch the pages in the allocated region ? If the later (and I do expect that), then how many pages do you need to touch before machine breaks ? Is it single access that causes the havoc, or you need to touch the amount approximately equal to RAM+swap ? --6VIkwkuKQ8ml0fyB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7WY1AACgkQC3+MBN1Mb4j1awCg4DC4/lm/16bbiU0luriAlULM GjkAn3HkCD8WtD35Kys03IPHFtXlY6If =xbz2 -----END PGP SIGNATURE----- --6VIkwkuKQ8ml0fyB--