On Tue, Nov 08, 2022 at 01:14:02PM +0000, Martin Pieuchot wrote:
> 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, \
>
Works here. This doesn't move the needle as much as the mmap unlock diff did
though :)
