Now that mmap/munmap/mprotect(2) are no longer creating contention it is
possible to see that sched_yield(2) is one of the syscalls waiting for
the KERNEL_LOCK() to be released. However this is no longer necessary.
Traversing `ps_threads' require either the KERNEL_LOCK() or the
SCHED_LOCK() and we are holding both in this case. So let's drop the
requirement for the KERNEL_LOCK().
ok?
Index: kern/syscalls.master
===================================================================
RCS file: /cvs/src/sys/kern/syscalls.master,v
retrieving revision 1.235
diff -u -p -r1.235 syscalls.master
--- kern/syscalls.master 8 Nov 2022 11:05:57 -0000 1.235
+++ kern/syscalls.master 8 Nov 2022 13:09:10 -0000
@@ -531,7 +531,7 @@
#else
297 UNIMPL
#endif
-298 STD { int sys_sched_yield(void); }
+298 STD NOLOCK { int sys_sched_yield(void); }
299 STD NOLOCK { pid_t sys_getthrid(void); }
300 OBSOL t32___thrsleep
301 STD NOLOCK { int sys___thrwakeup(const volatile void *ident, \
