On Sun, Oct 03, 2021 at 08:05:17AM +0000, Visa Hankala wrote:
> 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); }
Testers would be very helpful here. I have not received any feedback
so far.
Note that this unlocking is separate from the kqueue backend work
of poll(2) and select(2). I would prefer to be fairly confident on
the MP-safety of kevent(2) before the unlocking of kqueue-based poll(2)
and select(2) is even considered because kevent(2) is the native
interface to the kqueue subsystem.
