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

[Carlos O'Donell]

On 4/5/19 6:01 AM, Florian Weimer wrote:
> * 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.

Unless you run out of mappings? The kernel must handle CLONE_CHILD_CLEARTID
in a timely fashion or glibc will be unable to free the stacks and the cache
could grow beyond the maximum limit (note that free_stacks() is only a
one-shot attempt to lower the limit and does not need to succeed).

> 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.

Agreed.

-- 
Cheers,
Carlos.