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: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: nd at arm dot com, Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>, Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Jeff Law <law at redhat dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, James Greenhalgh <James dot Greenhalgh at arm dot com>
- Date: Fri, 08 Dec 2017 18:28:24 +0000
- Subject: Re: [RFC] nptl: change default stack guard size of threads
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- Nodisclaimer: True
- References: <5A1ECB40.9080801@arm.com> <76c38ecf-6497-c96c-5c8c-95cceed100a5@redhat.com> <5A1EFF28.9050406@arm.com> <5c796246-1907-8cf4-00fc-eee11614b092@redhat.com> <HE1PR0801MB205834BDB77C2208C953FD2E833B0@HE1PR0801MB2058.eurprd08.prod.outlook.com> <91691187-15ae-e740-bea6-94eff4172263@redhat.com> <DB6PR0801MB20537C3F43D7C428E5EEE77583320@DB6PR0801MB2053.eurprd08.prod.outlook.com> <5A2855F9.8040901@arm.com> <20171206220751.GW1627@brightrain.aerifal.cx>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 06/12/17 22:07, Rich Felker wrote:
> On Wed, Dec 06, 2017 at 08:41:29PM +0000, Szabolcs Nagy wrote:
>> On 06/12/17 14:27, Wilco Dijkstra wrote:
>>> Florian Weimer wrote:
>>>> On 11/29/2017 11:28 PM, Wilco Dijkstra wrote:
>>>>> It's not related to what GLIBC needs, but GLIBC, like Linux, must continue to
>>>>> run old binaries so a larger guard size is definitely beneficial. No existing code
>>>>> uses probing, so increasing the guard size means far fewer functions could
>>>>> jump the guard. The dropoff is exponential, each doubling of guard page size
>>>>> halves the number of functions with a stack larger than the guard size.
>>>>
>>>> That's not actually true in the sense that the math doesn't work out
>>>> that way. If you have a weird function which skips by a really large
>>>> amount, you can double the guard size many, many times until the number
>>>> of unprotected functions drops further.
>>>>
>>>> And there is definitely a long tail here, due to GNU's affinity to
>>>> variable-length arrays and alloca.
>>>
>>> The math works fine for most of the curve. The measurements I did
>>> show that the number of functions with really large stack allocations is
>>> extremely small. So it's a long tail only in terms of maximum stack
>>> allocation, not in number of functions.
>>
>> with 4k probe interval about 1% of functions need probes
>> with 64k probe interval about 0.01% (order of magnitude,
>> alloca not included), so increasing the default guard can
>> be useful for existing code.
>
> Rather than what % of all functions need probes, I think it would be
> more meaningful to ask what % of functions with a useful (not trivial
> error) code path less than N instructions (for N=100 or so) need
> probes. My hypothesis is that, for either threshold 4k or 64k, the %
> is negligible.
>
that is hard to tell, (because we don't know which path
is hot/cold and a big function can have a short hot path)
previously spec17 was analyzed with gcc instrumentation,
now i disasmd the binaries of about 5000 deb packages
all insn: 448415942
sp:=reg: 452
sp-=reg: 12903
sp-=imm: 4199819
imm>4096-128: 14809, 0.353%
imm>16384-512: 2703, 0.064%
imm>32768-1024: 1370, 0.033%
imm>65536-1024: 809, 0.019%
(the threshold values are not exact power of 2 to leave
space for outgoing args, otherwise every function with
outgoing args would need additional probes)
the >4k stack use is rarer in this set than in spec17.
sp-=reg is an alloca usually, when reg had a constant
value it was counted as sp-=imm, but accounting may
not be perfect here.
mov to sp (sp:=reg) is usually save and restore of the
sp around local vla use (frame pointer is not counted),
but it may be an alloca too (only counted if it seemed
it could be an alloca)
sp-=imm should be a good approximation of number of
functions with stack use, but in some cases there are
two stack adjustments in the same function (this is
used for the % numbers).
largest static stack use (some of them are in libraries):
./usr/bin/qpdldecode: 5246976
./usr/bin/ddstdecode: 4124672
./usr/lib/aarch64-linux-gnu/libgfortran.so.4.0.0: 2098912
./usr/lib/aarch64-linux-gnu/sane/libsane-hp4200.so.1.0.25: 1994752
./usr/bin/foomatic-combo-xml: 1130496
./usr/lib/aarch64-linux-gnu/sane/libsane-umax_pp.so.1.0.25: 1069056
./usr/bin/umax_pp: 1069056
./lib/aarch64-linux-gnu/libcryptsetup.so.4.7.0: 1048672
./usr/lib/aarch64-linux-gnu/libCbcSolver.so.3.9.9: 1000528
./usr/lib/aarch64-linux-gnu/libv4lconvert0/ov511-decomp: 999424
./usr/lib/aarch64-linux-gnu/libvtkRenderingVolume-6.3.so.6.3.0: 800256
./usr/lib/inkscape/libinkscape_base.so: 718768
./usr/lib/aarch64-linux-gnu/libv4lconvert0/ov518-decomp: 696320
./usr/lib/aarch64-linux-gnu/libcdaudio.so.1.0.0: 569344
./usr/lib/aarch64-linux-gnu/openmpi/lib/openmpi/mca_btl_tcp.so: 524672
./usr/lib/apt/methods/rred: 524656
./usr/bin/ttf2tfm: 524656
./usr/lib/aarch64-linux-gnu/libvtkImagingColor-6.3.so.6.3.0: 524608
./usr/bin/luatex: 524592
./usr/lib/libgnustep-base.so.1.25.0: 524464
./usr/bin/ufraw-batch: 524384
./usr/bin/png-fix-itxt: 500128
and top binaries by alloca count:
./usr/lib/python2.7/dist-packages/cryptography/hazmat/bindings/_openssl.aarch64-linux-gnu.so: 1920
./usr/lib/gcc/aarch64-linux-gnu/7/cc1plus: 302
./usr/lib/gcc/aarch64-linux-gnu/6/cc1plus: 290
./usr/lib/aarch64-linux-gnu/s2tc/libtxc_dxtn.so: 282
./usr/lib/gcc/aarch64-linux-gnu/7/cc1: 270
./usr/lib/gcc/aarch64-linux-gnu/6/cc1: 257
./usr/bin/gdb: 247
./usr/lib/libgnustep-base.so.1.25.0: 244
./usr/bin/gdb: 241
./usr/lib/gcc/aarch64-linux-gnu/7/lto1: 237
./usr/lib/gcc/aarch64-linux-gnu/6/lto1: 224
./usr/lib/aarch64-linux-gnu/libgmp.so.10.3.2: 217
./lib/systemd/libsystemd-shared-235.so: 210
./usr/lib/thunderbird/libxul.so: 148
./lib/aarch64-linux-gnu/libc-2.25.so: 148
./sbin/ldconfig: 143
./usr/lib/firefox-esr/libxul.so: 142
./usr/lib/aarch64-linux-gnu/libopus.so.0.6.1: 138
./usr/lib/aarch64-linux-gnu/libgcj.so.17.0.0: 134
./usr/lib/libcln.so.6.0.4: 110
./usr/lib/aarch64-linux-gnu/libspeex.so.1.5.0: 104
./sbin/brltty: 102