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.orgReceived 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