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: Florian Weimer <fweimer at redhat dot com>
- To: 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 16:18:38 +0100
- Subject: Re: [RFC] nptl: change default stack guard size of threads
- Authentication-results: sourceware.org; auth=none
- References: <5A1ECB40.9080801@arm.com>
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.
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.
Thanks,
Florian