This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 4/4] rseq registration tests (v2)


* 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]