On 19/10/2025 08:08, Collin Funk wrote:
I was curious about the performance of posix_spawn, so I wrote a test program to experiment with, attached to this message.Here is my testing: # Using fork + execvp to execute 'true' 10000 times. $ gcc main.c $ perf stat --repeat 5 ./a.out 2>&1 | grep -F 'seconds time elapsed' 5.8890 +- 0.0761 seconds time elapsed ( +- 1.29% ) # Using vfork + execvp $ gcc -DFORK=vfork main.c $ perf stat --repeat 5 ./a.out 2>&1 | grep -F 'seconds time elapsed' 4.4907 +- 0.0596 seconds time elapsed ( +- 1.33% ) # Using posix_spawnp $ gcc -DUSE_POSIX_SPAWN=1 main.c $ perf stat --repeat 5 ./a.out 2>&1 | grep -F 'seconds time elapsed' 4.6260 +- 0.0508 seconds time elapsed ( +- 1.10% ) It seems like this is due to the different clone flags: # fork + execvp clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7ff8b35f6a10) # posix_spawnp clone3({flags=CLONE_VM|CLONE_VFORK|CLONE_CLEAR_SIGHAND, exit_signal=SIGCHLD, stack=0x7f9978d00000, stack_size=0x9000} The vfork man-page says that it uses "CLONE_VM | CLONE_VFORK | SIGCHLD" [1]. How about using posix_spawn in coreutils where possible (that is, not 'env' which does not fork)? The micro-optimization could add up for for 'install -s'. It would also help port to Windows, which does not have fork and vfork. The code in src/split.c also looks like a good candidate for posix_spawn_file_actions_adddup2, etc. [2]. Collin [1] https://man7.org/linux/man-pages/man2/vfork.2.html [2] https://pubs.opengroup.org/onlinepubs/9699919799/
I think posix_spawn would be useful when exec'ing something immediately after fork(), as you then don't have the overhead of memory accounting for the fork. This is especially useful when the memory used by a program is large. For example a large sort --compress can hit this, as mentioned a little while ago: https://lists.gnu.org/archive/html/coreutils/2025-10/msg00059.html I.e. this is not just a perf benefit, but can unblock some workflows. The specific sort issue was discussed at https://unix.stackexchange.com/a/275557/37127, where I noted glibc's implementation was just becoming usable, which definitely should be the case by now. cheers, Padraig
