On Thu, Dec 20, 2018 at 12:19 PM Adhemerval Zanella <adhemerval.zanella@xxxxxxxxxx> wrote: > On 19/12/2018 20:23, Vineet Gupta wrote: > > 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. > > The only advantage of using a larger sigset_t from glibc standpoint is if > kernel ever change it maximum number of supported signals it would not be > a ABI change (it would be if glibc provided sigset_t need to be extended). > > My point was that this change would hardly help in performance or memory > utilization due the signal set common utilization in exported and internal > API. But at the same time the signal set hasn't been changed for a *long* time > and I don't see indication that it will any time soon. So a new architecture > might indeed assume it won't change and set its default to follow Linux user > ABI. I just checked again what we actually use in the kernel. With very few exceptions, all architectures in current kernels use #define _NSIG 64 #define _NSIG_WORDS (_NSIG / _NSIG_BPW) typedef struct { /* this sucks for big-endian 32-bit compat mode */ unsigned long sig[_NSIG_WORDS]; } sigset_t; The only two exceptions I see are: - alpha uses a scalar 'unsigned long' instead of the struct+array, but the effect is the same layout. - For unknown reasons, all three MIPS ABIs now use _NSIG=128. This changed during linux-2.1.x from 65, to 32 and then the current value... All users of sigset_t that I could find in the kernel just check the size argument to ensure it matches _NSIG, and return EINVAL otherwise. Arnd _______________________________________________ linux-snps-arc mailing list linux-snps-arc@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
