From nobody Tue Oct 24 22:02:53 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SFQzL2HMDz4xZnF for ; Tue, 24 Oct 2023 22:02:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SFQzL0cpcz3D8N for ; Tue, 24 Oct 2023 22:02:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1698184974; a=rsa-sha256; cv=none; b=MVozzEKnsUnTjkmSQgt8n7LDOuQcNKdt7zOq1u3yrBEfiLVeanc+pU0EGANgagbmajXO96 vIdCJ1S6dovtGobLn4bJ6zhQUnLdhkLYTLvPXnS9jp83Muz+LTyCEw9Dzh03fppDvo0qGO xhGZj8GoY5YNZjUiY2CELFdbvx1NbkzRzuou+pLGi4b3Hm1vnsD/+7hhU33mkzHQxEx2NX C88wa1TgQ4h2BUpA3QHiU5RAiIdUKfo0F7RiTolb5B0f6508ou0Mq/0YfNsCc3fMKE9Hku STCIFEZ0z4vgYxEnrmb7IqjhgwcJzLBFKNegsy1WPXdC6Rj8dwIkl5ZpEzpe2w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1698184974; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=RBgmi0TbfQFoq2wGfiaelUBZx7ge43EEG4iO9a0bmwA=; b=YJpStwwU72XktTajQNY0dc6VLaTEbQxB6MS+PTcqCu3hTHYKTr9gMqpcz/YjAwJ1eHPLMg kI4JON/PE9AXVLSvubycRX7Atr5AHsdNXy5jfEBDJB4FNFl0ntxdsTp6Ean+fsjJkKdoRM Nim5pCNvWdU30GxnShnXtLzHXKlztI4JQeB1B+Hsuf0E3zlCkBqvT9yAKuwGIxvg05Gw8d a/0sGKMbH5nhwa1A47AT6gimrdNFswr/FpGm40N8XEINJHrkbb+mNXUOnM6P1CarAU4Qw2 aBEayTAn/gBxWDjTTNJ5Sh8e4mrogj5/SFNDjikK35Z6iohh7BvAp4kLTHh6mw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4SFQzK6ncmzflp for ; Tue, 24 Oct 2023 22:02:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 39OM2rdw051840 for ; Tue, 24 Oct 2023 22:02:53 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 39OM2rQZ051839 for freebsd-arm@FreeBSD.org; Tue, 24 Oct 2023 22:02:53 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 274705] unreasonably large stack reservation for armv7 processes on arm64 Date: Tue, 24 Oct 2023 22:02:53 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 13.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: fuz@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: mfc-stable13? mfc-stable14? X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc attachments.mimetype flagtypes.name attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D274705 Bug ID: 274705 Summary: unreasonably large stack reservation for armv7 processes on arm64 Product: Base System Version: 13.2-STABLE Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: fuz@FreeBSD.org CC: cognet@FreeBSD.org, kib@FreeBSD.org Attachment #245854 text/plain mime type: Flags: mfc-stable13?, mfc-stable14? Created attachment 245854 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D245854&action= =3Dedit memory-wasting test program I am trying to understand why armv7 processes on arm64 can only allocate ar= ound 2 GB of memory despite being allowed to use the whole 4GB of virtual address space. Debugging with kib, we found that 1 GB of address space is reserved for the stack starting around the 3 GB mark. As mmap() doesn't try to find memory beyond the stack, this limits it to finding memory between text and stack, which amounts to around 2 GB. Running the attached test program, it fails after allocating 2022 buffers @= 1 MB each and we get a memory map like this: PID START END PRT RES PRES REF SHD FLAG TP PATH 2844 0x10000 0x11000 r-- 1 3 3 1 CN--- vn /usr/home/fuz/te= st 2844 0x20000 0x21000 r-x 1 3 3 1 CN--- vn /usr/home/fuz/te= st 2844 0x30000 0x31000 r-- 1 0 1 0 C---- vn /usr/home/fuz/te= st 2844 0x40000 0x41000 rw- 1 1 1 0 ----- df=20 2844 0x40040000 0x40045000 r-- 5 29 35 11 CN--- vn /libexec/ld-elf.= so.1 2844 0x40045000 0x4004b000 rw- 1 1 1 0 ----- df=20 2844 0x40054000 0x4006d000 r-x 25 29 35 11 CN--- vn /libexec/ld-elf.= so.1 2844 0x4007c000 0x4007d000 r-- 1 0 1 0 C---- vn /libexec/ld-elf.= so.1 2844 0x4008c000 0x400af000 rw- 20 20 1 0 ----- df=20 2844 0x400af000 0x400b3000 r-- 4 14 46 22 CN--- vn /lib/libgcc_s.so= .1 2844 0x400b3000 0x400c2000 --- 0 0 0 0 CN--- gd=20 2844 0x400c2000 0x400cc000 r-x 10 14 46 22 CN--- vn /lib/libgcc_s.so= .1 2844 0x400cc000 0x400db000 --- 0 0 0 0 CN--- gd=20 2844 0x400db000 0x400dc000 rw- 1 0 1 0 C---- vn /lib/libgcc_s.so= .1 2844 0x400dc000 0x400eb000 --- 0 0 0 0 CN--- gd=20 2844 0x400eb000 0x400ec000 rw- 1 0 1 0 C---- vn /lib/libgcc_s.so= .1 2844 0x400ec000 0x40133000 r-- 71 360 55 31 CN--- vn /lib/libc.so.7 2844 0x40133000 0x40142000 --- 0 0 0 0 CN--- gd=20 2844 0x40142000 0x40299000 r-x 282 360 55 31 CN--- vn /lib/libc.so.7 2844 0x40299000 0x402a8000 --- 0 0 0 0 CN--- gd=20 2844 0x402a8000 0x402ac000 r-- 4 0 2 0 C---- vn /lib/libc.so.7 2844 0x402ac000 0x402ad000 rw- 1 0 2 0 C---- vn /lib/libc.so.7 2844 0x402ad000 0x402bc000 --- 0 0 0 0 CN--- gd=20 2844 0x402bc000 0x402c1000 rw- 5 0 1 0 C---- vn /lib/libc.so.7 2844 0x402c1000 0x403de000 rw- 272 272 1 0 ----- df=20 2844 0x40400000 0x68981000 rw- 165235 165235 1 0 ----- df=20 2844 0x68a00000 0xba916000 rw- 335612 335612 1 0 ----- df=20 2844 0xbaa00000 0xbff4f000 rw- 20366 20366 1 0 ----- df=20 2844 0xbfffe000 0xfffde000 --- 0 0 0 0 ----- gd=20 2844 0xfffde000 0xffffe000 rw- 3 3 1 0 ---D- df=20 2844 0xffffe000 0xfffff000 r-x 1 1 161 0 ----- ph=20 clearly showing how a large guard mapping for the stack from 0xbfffe000 to 0xfffde000 prevents the heap from growing further. On the other side, mmap= () doesn't want to allocate below 0x40040000, cutting another GB off the avail= able memory for around 2GB left to allocate. Setting ulimit -Hs 65536 does not affect the behaviour, but compiling with -Wl,-z,stack-size=3D65536 does, reducing the size of the stack mapping. Perhaps the guard page sizes and mmap lower limits could be adjusted to the defaults used for i386 processes on amd64 hosts? --=20 You are receiving this mail because: You are the assignee for the bug.=