From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 22:23:59 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 C148A16A4CE for ; Thu, 11 Nov 2004 22:23:59 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B87543D39 for ; Thu, 11 Nov 2004 22:23:59 +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 iABMMj4N008636; Thu, 11 Nov 2004 17:22:45 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)iABMMjPT008633; Thu, 11 Nov 2004 22:22:45 GMT (envelope-from robert@fledge.watson.org) Date: Thu, 11 Nov 2004 22:22:45 +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 22:23:59 -0000 On Thu, 11 Nov 2004, Anurekh Saxena wrote: > > 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? > > I may be missing something fundamental here, but, doreti (exceptions.s) > does not call 'ast' for an interrupted task, that does not have RPL of 3 > (user). So, even if an interrupt is pending, and the 'NEEDRESCHED' is > set, the scheduling decision is delayed till the kernel thread or > whatever was running in the kernel sleeps, or give up the cpu(call > mi_switch), or returns to user mode. > > AFAIK this is the only return path from an interrupt. Unless there is > another return path for the interrupts, the scheduler is not invoked on > a return. Assuming we're talking about i386, lapic_handle_intr() will call intr_execute_handlers(), which will walk the list of handlers for the interrupt, and either directly invoke the fast handlers of the interrupts, or call ithread_schedule() to schedule the ithread. ithread_schedule() will invoke setrunqueue(), which enters the scheduler and is a preemption point. If you dig down a bit, you'll find a call to maybe_preempt(), which may preempt if appropriate, resulting in a call to mi_switch() to the ithread. The maybe_preempt() code will only kick in to actually switch if PREEMPTION is defined. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research