Bug 17714

Summary: possible priority inversion with use of idprio
Product: Base System Reporter: trost <trost>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description trost 2000-03-31 21:20:01 UTC 
	I have a startup script that starts setiathome at an idprio of
	31 and then starts up gf_client (a distributed gamma ray flux
	project) at an idprio of 30.  After startup, I noticed that "ps"
	had an "L" flag in the "STAT" column for setiathome (the lowest
	priority process).  The next command, "man ps", hung; then,
	"date" (or, more likely, the shell) hung in another window. At
	this point, I interrupted gf_client, and everything started
	working again.

	I presume that the problem was cause by a priority inversion
	where the setiathome client had somehow locked a page, but
	could not do whatever needed to be done with the page because
	gf_client was taking all available CPU cycles.

Fix: 

I would guess that locking a page in core should cause an
	increase in the process's priority, but I know nothing of the
	details.
How-To-Repeat: 
	Hah!  Good luck!  I have no idea how to make a process keep
	pages locked in core long enough to cause the problem.
Comment 1 hoek freebsd_committer freebsd_triage 2000-05-20 08:24:06 UTC 
State Changed
From-To: open->closed

You are correct that idprio has a priority inversion problem.  I 
am not sure about your hypothesized explanation, but the general 
problem is known and there is an earlier open PR describing the 
problem. 

Thanks. 

References: sys/kern/kern_synch.c and kern/5641 

The problem is not expected to be solved in the short term.  Hehe. 
Fixing it is a low-priority task for us.  :)