This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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/ 2098912
./usr/lib/aarch64-linux-gnu/sane/ 1994752
./usr/bin/foomatic-combo-xml: 1130496
./usr/lib/aarch64-linux-gnu/sane/ 1069056
./usr/bin/umax_pp: 1069056
./lib/aarch64-linux-gnu/ 1048672
./usr/lib/aarch64-linux-gnu/ 1000528
./usr/lib/aarch64-linux-gnu/libv4lconvert0/ov511-decomp: 999424
./usr/lib/aarch64-linux-gnu/ 800256
./usr/lib/inkscape/ 718768
./usr/lib/aarch64-linux-gnu/libv4lconvert0/ov518-decomp: 696320
./usr/lib/aarch64-linux-gnu/ 569344
./usr/lib/aarch64-linux-gnu/openmpi/lib/openmpi/ 524672
./usr/lib/apt/methods/rred: 524656
./usr/bin/ttf2tfm: 524656
./usr/lib/aarch64-linux-gnu/ 524608
./usr/bin/luatex: 524592
./usr/lib/ 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/ 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/ 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/ 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/ 217
./lib/systemd/ 210
./usr/lib/thunderbird/ 148
./lib/aarch64-linux-gnu/ 148
./sbin/ldconfig: 143
./usr/lib/firefox-esr/ 142
./usr/lib/aarch64-linux-gnu/ 138
./usr/lib/aarch64-linux-gnu/ 134
./usr/lib/ 110
./usr/lib/aarch64-linux-gnu/ 104
./sbin/brltty: 102

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]