blockable sleep lock (sleep mutex) 16

[Julian Elischer]

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)