This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 4/4] rseq registration tests (v2)
- From: Florian Weimer <fweimer at redhat dot com>
- To: Carlos O'Donell <codonell at redhat dot com>
- Cc: Mathieu Desnoyers <mathieu dot desnoyers at efficios dot com>, carlos <carlos at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>, libc-alpha <libc-alpha at sourceware dot org>, Thomas Gleixner <tglx at linutronix dot de>, Ben Maurer <bmaurer at fb dot com>, Peter Zijlstra <peterz at infradead dot org>, "Paul E. McKenney" <paulmck at linux dot vnet dot ibm dot com>, Boqun Feng <boqun dot feng at gmail dot com>, Will Deacon <will dot deacon at arm dot com>, Dave Watson <davejwatson at fb dot com>, Paul Turner <pjt at google dot com>
- Date: Fri, 05 Apr 2019 12:01:04 +0200
- Subject: Re: [PATCH 4/4] rseq registration tests (v2)
- References: <20190212194253.1951-1-mathieu.desnoyers@efficios.com> <20190212194253.1951-5-mathieu.desnoyers@efficios.com> <bba18ac5-ec26-9fc6-689c-a499f4028047@redhat.com> <1950762361.2578.1554408264573.JavaMail.zimbra@efficios.com> <fc35274f-3723-1cf3-bfe2-2bbf6c22438d@redhat.com>
* Carlos O'Donell:
> The above commit is a good example of a failure to provide a comment
> that gives intent for the implementation and therefore you have no
> idea why 1MiB was selected. Magic numbers should have comments, and
> a patch like the one you reference would not be accepted today.
>
> The only real worry we have with testing is thread reap rate which
> seems to be slow in the kernel and sometimes we've seen the kernel
> be unable to clone new threads because of this reason. Even then on
> the worst architecture, hppa, I can create ~300 threads in a test
> without any problems.
Delayed reaping in the kernel (after signaling thread exit) does *not*
affect the stack allocation. With a valid test, the stack is queued for
reuse. Only kernel-side data structures stick around.
My guess is that in 2004, 64-bit systems were still around that didn't
have enough physical backing store for 50 * 8 MiB thread stacks, so the
overcommit limiter in the kernel would kick in. I don't think this is a
problem anymore, and in the off chance that it is, you can still use
ulimit -s to reduce the default if necessary.
Thanks,
Florian