From owner-freebsd-arch@FreeBSD.ORG Wed Nov 30 20:01:22 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 E8A21106564A for ; Wed, 30 Nov 2011 20:01:22 +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 8438B8FC0A for ; Wed, 30 Nov 2011 20:01:22 +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 pAUK14GB050607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Nov 2011 22:01:04 +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 pAUK139b079858; Wed, 30 Nov 2011 22:01:03 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pAUK131t079857; Wed, 30 Nov 2011 22:01:03 +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 22:01:03 +0200 From: Kostik Belousov To: Andreas Tobler Message-ID: <20111130200103.GE50300@deviant.kiev.zoral.com.ua> References: <4ED5BE19.70805@fgznet.ch> <20111130162236.GA50300@deviant.kiev.zoral.com.ua> <4ED65F70.7050700@fgznet.ch> <20111130170936.GB50300@deviant.kiev.zoral.com.ua> <4ED66B75.3060409@fgznet.ch> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BJNipRl4fWPaRlLb" Content-Disposition: inline In-Reply-To: <4ED66B75.3060409@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 20:01:23 -0000 --BJNipRl4fWPaRlLb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 30, 2011 at 06:44:21PM +0100, Andreas Tobler wrote: > On 30.11.11 18:09, Kostik Belousov wrote: > >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'. T= he > >>>>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 tri= es > >>>>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 amd= 64. > >>>> > >>>>Can anybody explain me the situation, why do I not have a working lim= it > >>>>on powerpc64? > >>>> > >>>>The machine itself has 7GB RAM and 12GB swap. The amd64 where I compa= red > >>>>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. > >> > >>I can not login anymore, everything is stuck except the core control > >>mechanisms for example the fan controller. > >> > >>Top reports 'ugly' figures, below from a earlier try: > >> > >>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 Fr= ee > >>Swap: 12G Total, 9904M Used, 2383M Free, 80% Inuse, 178M Out > >> > >> 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. > >> > >>And after my mem and swap are full I see swap_pager_getswapspace(16)=20 > >>failed. > >> > >>In this state I can only power-cycle the machine. > >> > >>>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. > >> > >>I would expect that the 'system' does not allow me to allocate that much > >>of ram. > > > >Does the issue with machine going into limbo reproducable with the code > >you posted ? >=20 > If I understand you correctly, yes. I can launch the test case and the=20 > machine is immediately unusable. Means I can not kill the process nor=20 > can I log in. Also, top does not show anything useful. Again, let me restate my question: the single mmap() of the huge size is enough for powerpc64 machine to break apart ? What happen if you insert sleep(1000000); call before return ? Do not kill the process, I want to know is machine dead while the process sleeps. >=20 > The original test case where I discovered this behavior behaves a bit=20 > different. > http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/testsuite/23_containers= /vector/bool/modifiers/insert/31370.cc?revision=3D169421&view=3Dmarkup >=20 > Here I can follow how the ram and swap is eaten up. Top is reporting the= =20 > figures. If everything is 'full', the swaper errors start to appear on=20 > the console. >=20 > >Or, do you need to actually touch the pages in the allocated region ? >=20 > If I have to, how would I do that? You read or write into each page in the region. >=20 > >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 ? >=20 > Andreas --BJNipRl4fWPaRlLb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7Wi38ACgkQC3+MBN1Mb4g7lQCcDFAgpunUqroZKNwgwUPuHIEn +EMAniqJfv8Uhm2rq3WrqjOJ/aXUsM3J =J9ox -----END PGP SIGNATURE----- --BJNipRl4fWPaRlLb--