From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 19:56:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7245416A4CE for ; Tue, 12 Oct 2004 19:56:22 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42A1B43D1F for ; Tue, 12 Oct 2004 19:56:22 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 9027 invoked from network); 12 Oct 2004 19:56:22 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 12 Oct 2004 19:56:20 -0000 Received: from [10.50.40.210] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i9CJu5MK093602 for ; Tue, 12 Oct 2004 15:56:06 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: current@FreeBSD.org Date: Tue, 12 Oct 2004 15:49:14 -0400 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200410121549.14689.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx Subject: Possible fix for interactivity problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2004 19:56:22 -0000 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 @@ -189,6 +189,13 @@ } /* + * 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 @@ -208,15 +215,6 @@ } 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 <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org