This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] nptl: change default stack guard size of threads
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Cc: nd at arm dot com, Jeff Law <law at redhat dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>, Rich Felker <dalias at libc dot org>, James Greenhalgh <James dot Greenhalgh at arm dot com>
- Date: Wed, 29 Nov 2017 10:16:54 -0800
- Subject: Re: [RFC] nptl: change default stack guard size of threads
- Authentication-results: sourceware.org; auth=none
- References: <5A1ECB40.9080801@arm.com> <76c38ecf-6497-c96c-5c8c-95cceed100a5@redhat.com>
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.
> 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.
--
Cheers,
Carlos.