Date: Mon, 12 Jun 2006 08:59:39 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-smp@freebsd.org Cc: smp@freebsd.org, alfred@freebsd.org, current@freebsd.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: Optional MPSAFE syscalls aren't Message-ID: <200606120859.40898.jhb@freebsd.org> In-Reply-To: <20060611204118.GA34272@xor.obsecurity.org> References: <20060611204118.GA34272@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200606120859.40898.jhb>