diff options
author | Tavian Barnes <tavianator@tavianator.com> | 2021-11-17 14:33:01 -0500 |
---|---|---|
committer | Tavian Barnes <tavianator@tavianator.com> | 2021-11-17 14:49:04 -0500 |
commit | ac1d28ea6bf9c0bd7b41725095a5b41ac8a08121 (patch) | |
tree | fc546039470ce0c9f7daa2188be6bee915c7c6c1 /tests/test_execdir_ulimit.out | |
parent | 9b50adaaaa4fedc8bda6fcf32595ecf7a682fa8b (diff) | |
download | bfs-ac1d28ea6bf9c0bd7b41725095a5b41ac8a08121.tar.xz |
exec: Find ARG_MAX with binary search after E2BIG
Previously we would shrink the command by one argument at a time until a
successful execution. This is okay if the ARG_MAX estimate is just a
little bit off, but is terribly slow when it's off by a lot.
One situation where it's very far off is when a 32-bit build of bfs
launches a 64-bit binary. In this case, bfs thinks the argv pointers
are 4 bytes, while they actually take up 8 bytes. The performance is
quite bad:
$ time ./bfs-64 ~/code/linux -exec echo {} + >/dev/null
./bfs-64 ~/code/linux -exec echo {} + > /dev/null 0.03s user 0.07s system 99% cpu 0.095 total
$ time ./bfs-32 ~/code/linux -exec echo {} + >/dev/null
./bfs-32 ~/code/linux -exec echo {} + > /dev/null 0.08s user 10.33s system 100% cpu 10.390 total
After this change, performance is much better:
$ time ./bfs-32 ~/code/linux -exec echo {} + >/dev/null
./bfs-32 ~/code/linux -exec echo {} + > /dev/null 0.03s user 0.08s system 99% cpu 0.110 total
Diffstat (limited to 'tests/test_execdir_ulimit.out')
0 files changed, 0 insertions, 0 deletions