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: [PATCH 4/5] linux: Optimize posix_spawn spurious sigaction calls

On Wed, Oct 09, 2019 at 11:37:30AM +0200, 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.

Yeah, the time namespace patchset will introduce CLONE_NEWTIME and that
flag will only be possible with clone3() for obvious reasons. And I'm
pretty sure that a lot of database workloads will want that...

> 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.

In the future I would like certain sets of changes that we currently do
in a racy way in the child to be made right at process creation time.
Another flag that I has been in my mind for a long time is e.g.
pdeath_signal. There should probably be an extension to struct
clone_args that introduces a new member pdeath_signal which won't be
reset and will be delivered to the child once the parent dies.


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