Re: [RFC] nptl: change default stack guard size of threads

[Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>]

Rich Felker wrote:
>On Tue, Dec 19, 2017 at 09:41:03PM -0700, Jeff Law wrote:

>> I've believed all along that stack clash probing as implemented by GCC
>> is pretty damn cheap -- cheap enough that we ought to just turn it on by
>> default and move on to other more useful work items.  And I hold that
>> position regardless of whether or not the guard is 4k or 64k.
>> 
>> 64k is marginally better simply because there's less probing,
>> particularly in a functions that allocate something like char array of
>> MAXPATHLEN entries.  Based on what I've looked at on a distro-wide
>> basis, MAXPATHLEN arrays on the stack are the single biggest reasons we
>> have to probe in prologues.
>
> They're also almost certainly indicative of the function making
> syscalls, in which case <10 instructions for a probe are completely
> dominated by the syscall time (hundreds if not thousands of times
> larger).

Note the stats Szabolcs collected showed here were several packages
where the percentage of functions requiring probes at a 4KB probe size
was over 20%.

The probes themselves also cause new pages to be allocated which
might not be used. This is the drawback of allocating all stack space for
the whole function in the prolog and then doing probes. There is also the
issue that shrinkwrapping still doesn't work that well - if there is a single
use of a callee-save register, you have to create a stack even on a fast
exit path that doesn't use the stack.

An option to reduce stack usage would be to automatically use alloca for
large allocations that may not always be used.

Wilco