From owner-freebsd-arch@FreeBSD.ORG Fri Oct 1 15:27:13 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 3C93916A4CE for ; Fri, 1 Oct 2004 15:27:13 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id B962D43D39 for ; Fri, 1 Oct 2004 15:27:12 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 18323 invoked by uid 89); 1 Oct 2004 15:27:10 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 1 Oct 2004 15:27:10 -0000 Received: (qmail 18243 invoked by uid 89); 1 Oct 2004 15:27:09 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 1 Oct 2004 15:27:09 -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 i91FR8mt027692; Fri, 1 Oct 2004 11:27:08 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: Matthew Dillon In-Reply-To: <200410010757.i917vjac017409@apollo.backplane.com> References: <1096610130.21577.219.camel@palm.tree.com> <200410010757.i917vjac017409@apollo.backplane.com> Content-Type: text/plain Message-Id: <1096644427.25800.26.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 01 Oct 2004 11:27:08 -0400 Content-Transfer-Encoding: 7bit cc: Peter Holm cc: Julian Elischer cc: "freebsd-arch@freebsd.org" Subject: Re: sched_switch (sched_4bsd) may be preempted 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: Fri, 01 Oct 2004 15:27:13 -0000 On Fri, 2004-10-01 at 03:57, Matthew Dillon wrote: > I would put the entire scheduler core in a critical section, not just > the part you think needs to be there. It's just too critical a subsystem > to be able to make operational assumptions of that nature in. It is > what I do in the DragonFly LWKT core, BTW, and crazy as I am I would > never even consider trying to move the critical section further in. The core is wrapped in the sched_lock. And since it is a spin lock it is running in a critical section with interrupts disabled. The additional (recursive) critical_enter is just an abusive way to tell maybe_preempt* that it should not immediately switch. ( Yes - eventually there should be a better way to do this) > > I would not reset TDP_OWEPREEMPT there. If I understand its function > correctly you need to leave it intact in order to detect preemption > request races against the scheduler. Since at that point newtd may > be non-NULL and thus not cause another scheduling queue check to be > made before the next switch, you cannot safely clear the flag where you > are clearing it. This is all running in critical section and we just decided to switch and either have or will pick the best thread. Interrupts are locked. The additional critical section just prevents recursion problems by delaying unwanted switches in maybe_preempt* . Resetting TDP_OWEPREEMPT is perfectly save since we switch to the thread chosen while everything has been locked. Stephan