From owner-freebsd-current@FreeBSD.ORG Tue Aug 12 21:41:10 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 131DE35F for ; Tue, 12 Aug 2014 21:41:10 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E7A526FC for ; Tue, 12 Aug 2014 21:41:09 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::b12c:cfa9:8f26:5106] (unknown [IPv6:2001:7b8:3a7:0:b12c:cfa9:8f26:5106]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 929E95C44; Tue, 12 Aug 2014 23:40:58 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_487FA847-2072-4D21-B49E-FD4F6DD626EB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: libthr and main thread stack size From: Dimitry Andric In-Reply-To: <20140808112201.GC93733@kib.kiev.ua> Date: Tue, 12 Aug 2014 23:40:50 +0200 Message-Id: References: <53E36E84.4060806@ivan-labs.com> <20140808052807.GB93733@kib.kiev.ua> <53E48B38.9010607@ivan-labs.com> <20140808112201.GC93733@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1878.6) Cc: "Ivan A. Kosarev" , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 21:41:10 -0000 --Apple-Mail=_487FA847-2072-4D21-B49E-FD4F6DD626EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 08 Aug 2014, at 13:22, Konstantin Belousov = wrote: > On Fri, Aug 08, 2014 at 12:32:56PM +0400, Ivan A. Kosarev wrote: >>=20 >> On 08/08/2014 09:28 AM, Konstantin Belousov wrote: >>> On Thu, Aug 07, 2014 at 04:18:12PM +0400, Ivan A. Kosarev wrote: >>>> Hello, >>>>=20 >>>> According to libthr's thr_init.c (the 9.2 version) = init_main_thread() >>>> allocates s.c. "red zone" below the main stack in order to protect = other >>>> stacks. The size of the main stack is determined by the >>>> _thr_stack_initial variable that is declared extern though it = doesn't >>>> seem it can be changed. The value of the variable is set to 4M on = 64-bit >>>> platforms which is obviously not sufficient for the most of real = programs. >>>>=20 >>>> Can anyone please confirm that there is no way to increase the = stack >>>> size for the main thread and thus any program linked against libthr = has >>>> only a few megabytes of stack memory for its main thread--whatever = the >>>> system stack size (ulimit -s) is set to? >>> Yes, there is no way to change the main thread stack clamping. >>> Could you provide a reasonable use case for the 4MB stack ? >>=20 >> Traversing trees with recursive functions or on-stack grammar = parsers? I just ran into a similar issue while running one of clang 3.5's test cases (see http://llvm.org/PR20635 ). On i386, it used up approximately 2MB of stack, then ran into the guard page, and segfaulted. I was quite amazed to find out that ulimit -s didn't help at all, until I remembered this thread. :-) >>> Anyway, I somewhat sympathize to the idea to stop clamping the main >>> thread stack, and to not reuse it for other threads stack carving. >>> This also means that non-main threads stack allocator should stop >>> tracking the explicit location for the stacks and rely on vm mmap(2) >>> base selection instead. >>=20 >> Yes, that would solve the problem. >>=20 >>> I do not know the motivations why the current scheme of stacks = allocation >>> was chosen. The changes do not look too involved. > In fact, I can resonably explain the current behaviour. The motivation > seems to come from desire to interpret the RLIMIT_STACK as the global > limit to the stack usage by all threads. =46rom this PoV, it becomes = clean > why the other thread stacks are carved from the main stack. Linux seems to interpret it as the default stack size for *each* new thread (so I guess that also includes the "main" thread, if Linux has such a concept): ''On Linux/x86-32, the default stack size for a new thread is 2 megabytes. Under the NPTL threading implementation, if the RLIMIT_STACK soft resource limit at the time the program started has any value other than "unlimited", then it determines the default stack size of new threads.'' > Below is the patch which adds environment variable = LIBPTHREAD_BIGSTACK_MAIN. > Setting it to any value results in the main thread stack left as is, = and > other threads allocate stack below the area of RLIMIT_STACK. Try it. > I do not want to set this behaviour as default. It works for my case, thanks. I'm not sure if we should use Linux's behavior of using RLIMIT_STACK for *all* threads, but I would definitely expect that value for the main thread by default... -Dimitry --Apple-Mail=_487FA847-2072-4D21-B49E-FD4F6DD626EB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlPqiegACgkQsF6jCi4glqOj/wCfaYWKzF3B4zmR3T3KWjG6Bn49 0wcAn0R52eUpesd+ooo+a9QNTvS2nfpP =HRkH -----END PGP SIGNATURE----- --Apple-Mail=_487FA847-2072-4D21-B49E-FD4F6DD626EB--