Date: Mon, 13 Jul 2009 19:49:24 +0100 From: "Robert N. M. Watson" <rwatson@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org, Sebastian Huber <sebastian.huber@embedded-brains.de> Subject: Re: callout(9) and Giant lock Message-ID: <732D77F4-6D18-4724-A76C-FB38B9DAE0F1@freebsd.org> In-Reply-To: <200907131417.53876.jhb@freebsd.org> References: <4A4740B8.8090205@embedded-brains.de> <alpine.BSF.2.00.0906281653160.69417@fledge.watson.org> <200907131417.53876.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13 Jul 2009, at 19:17, John Baldwin wrote: >> Callouts are marked as MPSAFE or non-MPSAFE when registered. If >> non-MPSAFE, >> we will acquire Giant automatically for the callout, but I believe >> we'll also >> try and sort non-MPSAFE callouts behind MPSAFE ones in execution >> order to >> minimize latency for MPSAFE callouts. Most callouts acquire locks >> of some >> sort, and stalling any callout indefinitely will stall the entire >> callout >> thread indefinitely, which in turn could lead to a variety of odd >> behaviors >> and potentially (although not necessarily) deadlock. > > FWIW, we do not actually sort the callouts in this manner, so all > callouts > will be blocked until Giant is acquired. I must have been remembering a proposed change -- as you say, it's certainly not in kern_timeout.c. However, I'd rather just eliminate support for Giant in callouts in 9.x than try to further facilitate them :-) Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?732D77F4-6D18-4724-A76C-FB38B9DAE0F1>