Optional MPSAFE syscalls aren't

John Baldwin jhb at freebsd.org
Mon Jun 12 13:28:30 UTC 2006

On Sunday 11 June 2006 16:41, Kris Kennaway wrote:
> rwatson, pjd and I tracked down the following problem when looking at
> postgresql profiling traces:
> For syscalls that are part of subsystems that may be loaded from kld,
> the SYSCALL_MODULE_HELPER() spams the copy of the sysent from
> syscalls.master - and it never sets the SYF_MPSAFE flag.  This means
> that regardless of what syscalls.master says about mpsafety, such
> syscalls always acquire Giant.
> One sad consequence of this is that when I removed the
> SYSCALL_MODULE_HELPERs from sysv_sem.c to get rid of the bogus Giant
> locking that seems to be hurting performance, postgresql hangs when
> trying to start; possibly the locking in sysv_sem.c is just broken
> since it was always implicitly serialized by Giant, so never in fact
> tested at all.
> Apart from the SYSV IPC syscalls, this also affects the AIO and mqueue
> code.

I actually plan to just remove the SYF_MPSAFE flag soon anyways and just push 
Giant down manually into the handful of syscalls that still need it.

John Baldwin

More information about the freebsd-smp mailing list