Re: Interrupt storms with wm(4)
On Fri, Oct 15, 2021 at 02:10:32AM +, Emmanuel Dreyfus wrote: > The wm0 interface gets a lot of interrupts. On low usage, CPU > is spent around 10% in interrupts. It can rise to more than 80%. > See below what systat vm says when the machine is quiet. > ioapic0 pin 16 is the wm0 interface. Is it the only device using that pin? If so, can you add an event counter or so to wm_intr to check what percentage of calls to wm_intr return handled == 0? Joerg
Request for implementation of KERN_PROC_SIGTRAMP sysctl
Is it possible for NetBSD to implement KERN_PROC_SIGTRAMP sysctl? TLDR; For several years, the GNAT Ada compiler has not been able to unwind a stack containing a signal trampoline. The unwinder I wrote for gcc several years ago just stopped working on newer NetBSD release even though the signal trampoline code itself did not change. FreeBSD and DragonFly BSD are immune to sigtramp location changes because they've introduced the KERN_PROC_SIGTRAMP sysctl which provides the location of the signal tramp of the process. It would be awesome if the NetBSD kernel provided the same functionality, at least on x86. I've recently been a part of an effort to revive the GNAT portion of current GCC releases. We succeeded with GCC 10.3 (in pkgsrc WIP) and GCC 11.2.0 in Ravenports (soon to support NetBSD), but the testsuite indicates it can no longer unwind properly. The previous technique (shown below) no longer works - I suspect the signal trampoline location changed to inaccessible memory somewhere along the line. With a sysctl like KERN_PROC_SIGTRAMP, we should be able to bring GNAT functionality back to the level of FreeBSD and DragonFly. It could also be used in debuggers like GDB and other compilers (Go? Rust?) I believe this sysctl would be useful so I'm hopeful somebody can implement it. History: FreeBSD added the functionality in November 2013. The current location of the code is here: https://github.com/freebsd/freebsd-src/blob/main/sys/kern/kern_proc.c#L3010 DragonFly added the functionality in March 2017. The current location of the code is here: https://github.com/DragonFlyBSD/DragonFlyBSD/blob/master/sys/kern/kern_proc.c#L2120 GCC unwind code that no longer works: https://github.com/jrmarino/draco/blob/netbsd-unwind/v11/libgcc/config/i386/netbsd-unwind.h Example of unwind code with KERN_PROC_SIGTRAMP (GCC): https://github.com/gcc-mirror/gcc/blob/master/libgcc/config/i386/freebsd-unwind.h Example of unwind code with KERN_PROC_SIGTRAMP (GDB): https://github.com/bminor/binutils-gdb/blob/master/gdb/amd64-fbsd-nat.c#L302 Regards, John Marino
Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl
On Fri, Oct 15, 2021 at 14:44:16 -0500, John Marino (NetBSD) wrote:
> Is it possible for NetBSD to implement KERN_PROC_SIGTRAMP sysctl?
>
> TLDR;
> For several years, the GNAT Ada compiler has not been able to unwind a
> stack containing a signal trampoline. The unwinder I wrote for gcc
> several years ago just stopped working on newer NetBSD release even
> though the signal trampoline code itself did not change. FreeBSD and
> DragonFly BSD are immune to sigtramp location changes because they've
> introduced the KERN_PROC_SIGTRAMP sysctl which provides the location
> of the signal tramp of the process.
It's been ages since I touched this area, but don't we have
per-sigaction trampolines? I mean, in practice they all use the same
__sigtramp_siginfo_$version trampoline, that sigaction passes to the
actual syscall, but in principle the process can have different
trampolines for different signals, can't it?
struct sys___sigaction_sigtramp_args {
syscallarg(int) signum;
syscallarg(const struct sigaction *) nsa;
syscallarg(struct sigaction *) osa;
syscallarg(const void *) tramp; // <-
syscallarg(int) vers;
};
-uwe
Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl
On Fri, Oct 15, 2021 at 23:14:39 +0300, Valery Ushakov wrote:
> On Fri, Oct 15, 2021 at 14:44:16 -0500, John Marino (NetBSD) wrote:
>
> > Is it possible for NetBSD to implement KERN_PROC_SIGTRAMP sysctl?
>
> It's been ages since I touched this area, but don't we have
> per-sigaction trampolines? I mean, in practice they all use the same
> __sigtramp_siginfo_$version trampoline, that sigaction passes to the
> actual syscall, but in principle the process can have different
> trampolines for different signals, can't it?
>
> struct sys___sigaction_sigtramp_args {
> syscallarg(int) signum;
> syscallarg(const struct sigaction *) nsa;
> syscallarg(struct sigaction *) osa;
> syscallarg(const void *) tramp; // <-
> syscallarg(int) vers;
> };
PS: We used to have a trampoline that the kernel copied out into the
process address space (bottom of the stack, iirc) - and that would be
something for KERN_PROC_SIGTRAMP to return indeed. But that was like
before netbsd 2.0, iirc.
-uwe
Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl
> On Oct 15, 2021, at 1:19 PM, Valery Ushakov wrote:
>
> On Fri, Oct 15, 2021 at 23:14:39 +0300, Valery Ushakov wrote:
>
>> On Fri, Oct 15, 2021 at 14:44:16 -0500, John Marino (NetBSD) wrote:
>>
>>> Is it possible for NetBSD to implement KERN_PROC_SIGTRAMP sysctl?
>>
>> It's been ages since I touched this area, but don't we have
>> per-sigaction trampolines? I mean, in practice they all use the same
>> __sigtramp_siginfo_$version trampoline, that sigaction passes to the
>> actual syscall, but in principle the process can have different
>> trampolines for different signals, can't it?
>>
>> struct sys___sigaction_sigtramp_args {
>> syscallarg(int) signum;
>> syscallarg(const struct sigaction *) nsa;
>> syscallarg(struct sigaction *) osa;
>> syscallarg(const void *) tramp; // <-
>> syscallarg(int) vers;
>> };
>
> PS: We used to have a trampoline that the kernel copied out into the
> process address space (bottom of the stack, iirc) - and that would be
> something for KERN_PROC_SIGTRAMP to return indeed. But that was like
> before netbsd 2.0, iirc.
Right, that was The Very Old Way. There is an API contract between libc and
the kernel vis a vis the signal trampoline, but the trampoline itself is in
libc, which could get mapped anywhere. So there is not a single static address
that could be returned, even per-process, because, as uwe points out, the
trampoline can be specified on a per-signal basis (there is one for "siginfo"
signal delivery and another for the old-style "sigcontext" signal delivery).
-- thorpej
