The internals of kqueue should now be safe without the kernel lock.
To keep changes relatively small, it is logical to unlock the kevent(2)
system call next. By doing this before unlocking any event filters,
it ought to be easier to untangle any problems that might crop up.
Please test. Experiences from normal interactive use would be valuable,
as it tends to stress the system in ways that test benches usually
do not cover.
After applying the patch, remember to run "make syscalls" in the
directory sys/kern/ before compiling the kernel.
It is possible that unlocking kevent(2) degrades performance somewhat
until more of the code gets unlocked. This is because the kernel-locked
region becomes more fragmented. This fragmentation increases the
frequency of kernel lock operations.
Index: kern/syscalls.master
===================================================================
RCS file: src/sys/kern/syscalls.master,v
retrieving revision 1.218
diff -u -p -r1.218 syscalls.master
--- kern/syscalls.master 4 Jun 2021 09:05:19 -0000 1.218
+++ kern/syscalls.master 3 Oct 2021 07:23:57 -0000
@@ -166,7 +166,7 @@
struct itimerval *itv); }
71 STD { int sys_select(int nd, fd_set *in, fd_set *ou, \
fd_set *ex, struct timeval *tv); }
-72 STD { int sys_kevent(int fd, \
+72 STD NOLOCK { int sys_kevent(int fd, \
const struct kevent *changelist, int nchanges, \
struct kevent *eventlist, int nevents, \
const struct timespec *timeout); }
