This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 4/5] linux: Optimize posix_spawn spurious sigaction calls
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Christian Brauner <christian dot brauner at ubuntu dot com>, libc-alpha at sourceware dot org
- Date: Mon, 7 Oct 2019 16:19:56 -0300
- Subject: Re: [PATCH 4/5] linux: Optimize posix_spawn spurious sigaction calls
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <20191007182526.qqmgziscbyxietve@wittgenstein> <firstname.lastname@example.org> <email@example.com>
On 07/10/2019 15:40, Florian Weimer wrote:
> * Adhemerval Zanella:
>> However, glibc supports older kernels as old as v3.2 and it will take
>> some years and releases to make v5.3 or new the minimum support kernel.
>> And I think it would be nice to have this optimization even for older
> But wouldn't it make sense to backport clone3 to these older kernels, so
> that further enhancements are possible, in cooperation with the kernel.
For a kernel standpoint sure, for libc one it only make sense if it becomes
de-facto kernel ABI. It can be quite feasible from a distribution standpoint,
where it controls both kernel and userland deployment. But it is not the only
scenario glibc aims to work neither we should prioritize it.
> I'm all for supporting older kernels, but performance optimizations for
> old kernels, merely to work around missing system call/flag support for
> things which are straightforward to backport into the kernel seems not
> the right priority to me, sorry.
Although the Linux idea is to use everything upstream, which means to have
the latest kernel up and running all the time a new is release; this is far
from reality and it won't change in nearby feature (although I do see some
steps towards it in various projects).
> If things can be fixed in the kernel, fix it there. That applies to
> both performance and functionality bugs.
I do agree with you, but this is mostly an engineering decision where it
aims to provide an optimization to a broader audience rather than to an
> Is this really important to you? Have seen this showing up in profiles?
Not right not, but mostly because projects usually do not use posix_spawn
as the way to spawn process. But over the years we not only fixed all its
various issues but also optimize in both memory and cpu usage and also added
some extra extensions that some projects had that prevent them to use
posix_spawn instead of the old fork plus execve.
So I expect that more and more posix_spawn should be the expected way to
spawn processes on Linux (some projects are indeed using it, such as
gnome3) and by avoiding ~120 syscall each time a process is spawned
is a nice performance improvement.