Date: Tue, 12 Aug 2014 23:40:50 +0200 From: Dimitry Andric <dim@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: "Ivan A. Kosarev" <ivan@ivan-labs.com>, freebsd-current@freebsd.org Subject: Re: libthr and main thread stack size Message-ID: <A736844B-9058-453E-8A43-097A08F741C9@FreeBSD.org> In-Reply-To: <20140808112201.GC93733@kib.kiev.ua> References: <53E36E84.4060806@ivan-labs.com> <20140808052807.GB93733@kib.kiev.ua> <53E48B38.9010607@ivan-labs.com> <20140808112201.GC93733@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <kostikbel@gmail.com> = 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A736844B-9058-453E-8A43-097A08F741C9>