From owner-freebsd-arch@FreeBSD.ORG Sat Sep 18 00:52:30 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CBFF16A4CE for ; Sat, 18 Sep 2004 00:52:30 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id E1D6743D1F for ; Sat, 18 Sep 2004 00:52:29 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 16815 invoked by uid 89); 18 Sep 2004 00:52:28 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 18 Sep 2004 00:52:28 -0000 Received: (qmail 16810 invoked by uid 89); 18 Sep 2004 00:52:28 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 18 Sep 2004 00:52:28 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id i8I0qRmt039011; Fri, 17 Sep 2004 20:52:27 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: "freebsd-arch@freebsd.org" Content-Type: text/plain Message-Id: <1095468747.31297.241.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 17 Sep 2004 20:52:27 -0400 Content-Transfer-Encoding: 7bit Subject: scheduler (sched_4bsd) questions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2004 00:52:30 -0000 Hi, I finally found some time to take a peek at the sched_4bsd scheduler and found two things I could not explain: It looks like the thread priority of a thread in the kernel is normally its user priority. ( Unless it slept with priority change or due to mutex priority inheritance) If this is true kernel threads can be preempted while holding for example the root vnode lock (or other important kernel resources) while not getting a chance to run until there are no more user processes with better priority. I am probably missing a priority adjustment on kernel entry somewhere but seem to be unable to find it :-( I am also stomped by the special case of adding a thread X with better priority than the current thread to the runqueue if they belong to the same ksegroup. In this case both kg_last_assigned and kg_avail_opennings might be zero and setrunqueue() will not call sched_add(). Because of this it looks like the current thread will neither be preempted not will TDF_NEEDRESCHED be set to force rescheduling at the kernel boundary. This situation should resolve itself at the next sched_switch - however this might take a long time. (Especially if essential interrupt threads are blocked by mutexes held by thread X) Thanks in advance for any hints. Stephan PS: I am impressed how clean and easy to read the scheduler sources are. Looks like a lot of hard work went into this.