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

[Rich Felker <dalias at libc dot org>]

On Wed, Nov 29, 2017 at 10:16:54AM -0800, Carlos O'Donell wrote:
> On 11/29/2017 07:18 AM, Florian Weimer wrote:
> > On 11/29/2017 03:59 PM, Szabolcs Nagy wrote:
> >> The change can be made for aarch64 only
> > 
> > That doesn't seem to be the case, looking at the patch.
> > 
> > So what you intended to do, exactly?
> > 
> > A 64 KiB probe interval on legacy 32-bit architectures is really a
> > no-go.  It means we have to increase the guard region size to 64 KiB.
> > But we cannot do that: The guard allocation comes out of the overall
> > thread stack size, and existing applications do not expect that 60K
> > of configured stack suddenly becomes unavailable.  Adding the guard
> > size on top of the allocation will break setups which are carefully
> > tuned for a maximum number of threads.
> 
> We cannot be held to account for carefully tuned applications, such
> applications have to be tuned again for newer glibc.
> 
> I think we *could* do this for 64-bit and 32-bit AArch64/ARM, but I
> don't see the value in doing it for 32-bit.

If 64k guard is mandatory for safety against jumping over the guard
zone, then I don't think it's possible to "re-tune" 32-bit apps for
the new requirement. This imposes a relatively small limit on possible
number of threads the process can create.

> > And that's what people actually do.  Here's an example:
> > 
> > “
> >  -Xss128k
> > 
> > Reduces the default maximum thread stack size, which allows more of the process' virtual memory address space to be used by the Java heap.
> > ”
> > 
> > <http://www.oracle.com/technetwork/java/tuning-139912.html>
> > 
> > We can likely support 64 KiB probe intervals on 64-bit architectures.
> > But given the impact on backwards compatibility, I really don't see
> > the benefit on (legacy) 32-bit.
> 
> I agree, this is expensive for 32-bit, without much reward.
> 
> Even on 64-bit, I would like to see bug 11787 fixed to move the guard
> page accounting out of the stack, and then you can make the guard page
> as big as you want without impacting the stack accounting.

I agree completely that guard page should not subtract from the usable
stack size but should be in addition to it. If glibc is not currently
behaving that way, I think it's a conformance bug. But making it big
on 32-bit quickly cuts into total available virtual address space if
you have a moderately large number of threads.

Rich