Date: Mon, 02 Feb 2009 10:09:06 -0800 From: Julian Elischer <julian@elischer.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org, =?UTF-8?B?Tmlrb2xhIEtuZcW+ZXZpxIc=?= <laladelausanne@gmail.com> Subject: Re: blockable sleep lock (sleep mutex) 16 Message-ID: <498736C2.3040207@elischer.org> In-Reply-To: <200902020845.21773.jhb@freebsd.org> References: <02026848-7F83-405C-B4F3-EDD8B47DA294@gmail.com> <32679C0A-28C1-4D7A-950C-580787F3971D@gmail.com> <200902020845.21773.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > On Monday 02 February 2009 7:33:08 am Nikola Knežević wrote: >> On 30 Jan 2009, at 18:11 , Nikola Knežević wrote: >> >>> This is the message buffer: >>> Unread portion of the kernel message buffer: >>> panic: blockable sleep lock (sleep mutex) 16 @ /usr/src/sys/vm/ >>> uma_core.c:1834 >>> Any hints where I should search for the cause? >> >> Ok, I solved this problem. I had a critical_enter/exit surrounding >> code which was calling a lot of mallocs. Now, I'm getting another >> message, which doesn't make any sense: >> >> ---8<--- >> --- trap 0, rip = 0, rsp = 0xffffffff87834d30, rbp = 0 --- >> uma_zalloc_arg: zone "256" with the following non-sleepable locks held: >> exclusive sleep mutex click_instance r = 0 (0xffffff00051b4540) locked >> @ sched.cc:441 >> --->8--- >> >> It says "non-sleepable locks", yet it classifies click_instance as >> sleep mutex. I think witness code should emit messages which are more >> clear. > > It is confusing, but you can't do an M_WAITOK malloc while holding a mutex. > Basically, sleeping actually means calling "*sleep() (such as mtx_sleep()) or > cv_*wait*()". Blocking on a mutex is not sleeping, it's "blocking". Some > locks (such as sx(9)) do "sleep" when you contest them. In the scheduler, > sleeping and blocking are actually quite different (blocking uses turnstiles > that handle priority inversions via priority propagation, sleeping uses sleep > queues which do not do any of that). The underyling idea is that mutexes > should be held for "short" periods of time, and that any sleeps are > potentially unbounded. Holding a mutex while sleeping could result in a > mutex being held for a long time. > the locking overview page man 9 locking tries to explain this.. I've been pestering John to proofread it and make suggestiosn for a while now. (nag nag)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?498736C2.3040207>