Re: [PATCH 4/5] linux: Optimize posix_spawn spurious sigaction calls

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 09/10/2019 06:37, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> 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
>>>> kernels.
>>>
>>> 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.
> 
> Sure.  But I think we should keep in mind here that this is not a
> localized optimization.  It optimizes posix_spawn with something that
> extends into something that is (at least superficially) completely
> unrelated.
> 
> If we can get kernel assistance for the optimization (and it looks like
> we'll receive it), we can avoid that complexity.  The patch Christian
> posted is very small.  It's on top of clone3, sure, but I expect that
> people will want the system call anyway for some container support case
> soon enough, so long-term maintained kernels will get it essentially for
> free.
> 
> Using the new clone3 flag looks inherently backportable to me on the
> glibc side.  Compared to that, the sigaction changes look a bit risky to
> me.

But still I don't see that this being more complex to backport as being
a impeding reason to push it upstream. Even we push the minimum kernel
version higher and remove the inherent minimum kernel version check, it
would be case where the posix_spawn signals reset will still trigger in
older kernels.

I give you that eventually we might remove this optimization once we
assume a minimum kernel version, but as I said this might take some
time and I think optimizing posix_spawn (along with adding the required
extensions developers see as useful) it a way to promote it over the
fork plus execve and its deficiencies.