Possible fix for interactivity problems

From: John Baldwin <jhb_at_FreeBSD.org>
Date: Tue, 12 Oct 2004 15:49:14 -0400
The code to manage priority changes in both schedulers currently don't handle 
all the edge cases and have exposed one bug in msleep() that results in the 
interactive priority "boost" not taking effect until the thread is woken up.  
That is, normally the boost helps the thread that goes to sleep be chosen 
over other threads when picking a thread to wakeup, but that doesn't 
currently happen because we bump the priority after we stick the thread on 
the sleep queue and our schedulers aren't currently smart enough to resort 
threads on sleep queues when their priority changes (I'm working on that).  
The patch below should fix that problem for most cases by bumping the 
priority before putting the thread on the sleep queue:

--- //depot/projects/smpng/sys/kern/kern_synch.c	2004/10/12 19:09:56
+++ //depot/user/jhb/needresched/kern/kern_synch.c	2004/10/12 19:26:30
_at__at_ -189,6 +189,13 _at__at_
 	}
 
 	/*
+	 * Adjust this thread's priority.
+	 */
+	mtx_lock_spin(&sched_lock);
+	sched_prio(td, priority & PRIMASK);
+	mtx_unlock_spin(&sched_lock);
+
+	/*
 	 * We put ourselves on the sleep queue and start our timeout
 	 * before calling thread_suspend_check, as we could stop there,
 	 * and a wakeup or a SIGCONT (or both) could occur while we were
_at__at_ -208,15 +215,6 _at__at_
 	} else
 		sig = 0;
 
-	/*
-	 * Adjust this thread's priority.
-	 *
-	 * XXX: do we need to save priority in td_base_pri?
-	 */
-	mtx_lock_spin(&sched_lock);
-	sched_prio(td, priority & PRIMASK);
-	mtx_unlock_spin(&sched_lock);
-
 	if (timo && catch)
 		rval = sleepq_timedwait_sig(ident, sig != 0);
 	else if (timo)

Let me know if this helps.

-- 
John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
Received on Tue Oct 12 2004 - 17:56:22 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:17 UTC