From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.3 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 6B5FF1F405 for ; Wed, 19 Dec 2018 22:24:08 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=SfKKiv5NmT9C9V9n t8zGZR2Jn55VYkcLeukgVRDCZY5+ZmwXlOgPqp63ohEfdeLXF+hMa7BPfsq9m/0i MZAnnQaWeo11V3eGVY5tps7leLW0nmk/uBxlLbFCeHgDeo1RgGuuMYeEmeHk9Tkt MoF6egQeTLmLFAV3NgZ2z09Xgdg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=prZl/C+16Q9K70MU2duei7 JnLAU=; b=cRSotyPrGtuHd6ivTwtEPgYmRcKWbT43VDjWHympdyxngGcCjl3+1u rdom/f1cmeZfzGxI4qQ+F6U6nL7QyeymlPnqXofRt330HP9lqmu7Nka1ec/14Mmk MBqnASgMngVAaSWyhrvxvTcNK/3PUVmduzExmAypptJzZoxSbaUuE= Received: (qmail 107254 invoked by alias); 19 Dec 2018 22:24:05 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 107194 invoked by uid 89); 19 Dec 2018 22:24:02 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: smtprelay.synopsys.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=synopsys.com; s=mail; t=1545258239; bh=au94EXW/cP15x2EALmZhOe/xDa2/J6iSNshue0VkllU=; h=Subject:To:CC:References:From:Date:In-Reply-To:From; b=KpF/qnewnsQLapksTo61zGQKe/ehWm3DXOl4zWGD8PHIzz54g7ILGcwTzvtia1NO/ QokdyKz8oLsIG2dheJRB7+GzdTIDzux4ZRb7smBfRZgYeqEsu+yhC9GN3TfWJyqvPn eHPV5jxpJu1CGrh+nFhNufjZMp5/ormSETfNo1HuzSMZtDdA7nC86qVHbup0H8mVkD O0W6D4jvuoBr9aGKi9rGO8lxgH4gyHzKZqg50g5muP9g+IFyILimcFQBOcxUAE+jsB dUrxZctCdvHu8Ha7SoOLHuFpjNcEEWA6ary7DgjliUunOYr4UgelEsGivl8wQCiwVQ rLlnQgFHEWnqw== Subject: Re: ARC vs. generic sigaction (was Re: [PATCH 08/21] ARC: Linux Syscall Interface) To: Adhemerval Zanella , Joseph Myers CC: , Newsgroups: gmane.comp.lib.glibc.alpha,gmane.linux.kernel.arc References: <1545167083-16764-1-git-send-email-vgupta@synopsys.com> <1545167083-16764-9-git-send-email-vgupta@synopsys.com> <5f512e48-e7fc-2233-febd-2e6a8bc2311b@synopsys.com> <05069752-0a66-d6ca-e249-5c702eec4e99@synopsys.com> <17fcd9f0-9843-8700-c936-7ab1eb8f2fd2@linaro.org> From: Vineet Gupta Openpgp: preference=signencrypt Message-ID: <906931a6-a281-8994-718f-da203890e7e9@synopsys.com> Date: Wed, 19 Dec 2018 14:23:49 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <17fcd9f0-9843-8700-c936-7ab1eb8f2fd2@linaro.org> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 12/19/18 2:00 PM, Adhemerval Zanella wrote: > > > One possibility is to define an arch-specific __sigset_t.h with a custom > _SIGSET_NWORDS value and add an optimization on Linux sigaction.c to check > if both kernel_sigaction and glibc sigaction share same size and internal > layout to use the struct as-is for syscall instead of copy to a temporary > value (similar to what we used to have on getdents). ARC would still have > arch-specific code and would be the only ABI to have a different sigset_t > though. I don't like ARC to single out either. But as Joseph suggests could this be starting point for arches of future. Assuming it does, would rather see this or the approach Joseph alluded to earlier [1] [1] http://lists.infradead.org/pipermail/linux-snps-arc/2018-December/005122.html > > However I *hardly* think sigaction is a hotspot in real world cases, usually > the signal action is defined once or in a very limited number of times. I am > not considering synthetic benchmarks, specially lmbench which in most cases > does not measure any useful metric. I tend to disagree. Coming from embedded linux background, I've found it immensely useful to compare 2 minimal systems: especially when distos, out-of-box packages, fancy benchmarks don't even exist. At any rate, my disagreement with status quo is not so much of optimize for ARC, but rather pointless spending of electrons. When we know that there are 64 signals at max, which need 64-bits, why bother shuffling around 1k bits, specially when one is starting afresh and there's no legacy crap getting in the way. The case of adding more signals in future is indeed theoretically possible but that will be an ABI change anyways. > Even for other sigset_t usage case I still > think an arch-specific definition should not make much difference: > > 1. setcontext: it would incur just in larger ucontext_t (kernel get/set > mask is done using kernel expected size). Also, taking in consideration > these interfaces were removed from POSIX.1-2008, the inherent performance > issues (signal set/restore will most likely dominate the overhead), and > some implementation issues (BZ#18135 for instance), I would say to not > bother to optimize it. > > 2. pselect, ppoll, epoll_pwait, posix_spawn (posix_spawnattr_t), sig*: > for functions that accept sigset as an argument it would incur in just > larger memory utilization without much performance overhead. Again, > runtime for these calls would be mostly dominate by syscall overhead > or kernel wait-time for events. > > 3. raise, etc: for function that might allocate a sigset_t internally it > will similar to 2. I agree that that in libc, pretty much anything will be dominated by syscall overhead, but still... > Now, if ARC intention is just to follow generic glibc linux ABI definitions, > it could just define its sigaction as (not tested): Indeed the ABI is etched in stone and I have a very similar code now, with slight difference. > * sysdeps/unix/sysv/linux/arc/sigaction.c > > --- > #define SA_RESTORER 0x04000000 > #include > > extern void restore_rt (void) asm ("__restore_rt") attribute_hidden; > > #define SET_SA_RESTORER(kact, act) \ > (kact)->sa_flags = (act)->sa_flags | SA_RESTORER; \ > (kact)->sa_restorer = &__default_rt_sa_restorer +#define SET_SA_RESTORER(kact, act) \ + ({ \ + if (!((kact)->sa_flags & SA_RESTORER)) \ + { \ + (kact)->sa_restorer = __default_rt_sa_restorer; \ + (kact)->sa_flags |= SA_RESTORER; \ + } \ + else \ + (kact)->sa_restorer = (act)->sa_restorer; \ + }) > > #define RESET_SA_RESTORER(act, kact) \ > (act)->sa_restorer = (kact)->sa_restorer > > static void __default_rt_sa_restorer(void) > { > INTERNAL_SYSCALL_DECL (err); > INTERNAL_SYSCALL_CALL (__NR_rt_sigreturn, err); > } > > #include