From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 21:47:34 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 795E216A4CE for ; Thu, 11 Nov 2004 21:47:34 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16E7F43D2F for ; Thu, 11 Nov 2004 21:47:34 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id iABLkKm4007785; Thu, 11 Nov 2004 16:46:20 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)iABLkKqH007782; Thu, 11 Nov 2004 21:46:20 GMT (envelope-from robert@fledge.watson.org) Date: Thu, 11 Nov 2004 21:46:20 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Anurekh Saxena In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: kernel: return from interrupt 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: Thu, 11 Nov 2004 21:47:34 -0000 On Thu, 11 Nov 2004, Anurekh Saxena wrote: > I was under the impression that the 5.3 release had an option for full > preemption. If I am correct, why does the kernel refuse to schedule on > a return_from_interrupt if its not going back to userland? I can > understand this being a problem if interrupts were nested, or return > from a page fault in a critical section. Please correct me if I am > wrong, but if a *high* priority interrupt thread is ready to run, it > should be given a chance. Presuming the *interrupted* kernel path is > going to give up the CPU fast enough is probably not a good idea. > > I hope I have sent this to the right mailing list. Even normal "options PREEMPTION" should do this. I know from tracing the kernel in 6.x that that's the way the system behaves out of the box; with PREEMPTION turned on in 5.x you should see the same behavior. One thing I often do see, FWIW, is that if you're on an SMP box, the ithread will get scheduled to run immediately on another CPU that's idle, so you won't actually preempt the thread on the current CPU other than for the interrupt handler. What behavior are you seeing that suggests this isn't happening with PREEMPTION compiled in? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research