From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54092 invoked by alias); 9 Oct 2019 12:17:35 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 54084 invoked by uid 89); 9 Oct 2019 12:17:34 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-qt1-f196.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=to:cc:references:from:openpgp:autocrypt:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dbIFrWCQg0hthr+YGtYnRbQ/DwLv93tBcf5KyNZgu5Y=; b=ennRpeh4jCkmEgPqQkfD1bizhgZErEsJY6ovqvRLPGNrFMUAM4MFyLQPw+mwW+tlVw E7oiNd7QDC3oNV1gVNgPGol0vZ1+GGQO/jOtPK7mvTDyL3VYiTkVyxRJ2/QPmR+xau20 nfZA3of4c1AVMN+03mVp4oIceKJ5o6CNseBLl7uozCbAaWN1JT34w4dXLvXCWr6O7NjE s4oo6uYs4R3JRZNE+Vp+kIBQs95qcHCvVWdMHSRG9SbPPY0rWg248v8HHpp3f8DOW54/ 81uqlGFzpZGcj+F2x22m8QgdHWjlpZjyMoQUKXU8WbNG0HueC1G//1NdhVZEEnJHdJ3z EsPQ== Return-Path: To: Florian Weimer Cc: Christian Brauner , libc-alpha@sourceware.org References: <20190731183136.21545-1-adhemerval.zanella@linaro.org> <20190731183136.21545-4-adhemerval.zanella@linaro.org> <875zmg9xjr.fsf@oldenburg2.str.redhat.com> <4266b563-5433-8bb9-78a2-af0ff14cab59@linaro.org> <87ftlj6k69.fsf@oldenburg2.str.redhat.com> <87v9uavnzs.fsf@oldenburg2.str.redhat.com> <95503672-bc82-c0bc-0a30-5724644b0037@linaro.org> <20191007182526.qqmgziscbyxietve@wittgenstein> <63aabf91-610f-27f9-bc22-96edbc1c9f5f@linaro.org> <8736g4flh0.fsf@oldenburg2.str.redhat.com> <8736g26yzp.fsf@oldenburg2.str.redhat.com> From: Adhemerval Zanella Openpgp: preference=signencrypt Subject: Re: [PATCH 4/5] linux: Optimize posix_spawn spurious sigaction calls Message-ID: Date: Wed, 09 Oct 2019 12:17:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <8736g26yzp.fsf@oldenburg2.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2019-10/txt/msg00250.txt.bz2 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.