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
[-- Attachment #1 --] 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: >> >> 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, >>>> >>>> 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. >>>> >>>> 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 ? >> >> 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. >> >> Yes, that would solve the problem. >> >>> 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. From 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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlPqiegACgkQsF6jCi4glqOj/wCfaYWKzF3B4zmR3T3KWjG6Bn49 0wcAn0R52eUpesd+ooo+a9QNTvS2nfpP =HRkH -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A736844B-9058-453E-8A43-097A08F741C9>